Re: [racket-dev] planet2 and versions

[David Vanderson]

I was professionally writing Ruby code as that community struggled 
through package issues.  I hope that experience can shed some light 
here.  Also I'd like to understand the basic use cases and how they work 
in planet2.


As a user, here are my 2 use cases:

1. My friend tells me about awesome library X, and I want to install it 
and use it.  Planet2 makes this easy.


2. I have an existing app running and I want to replicate it exactly 
somewhere else (including libraries).  I'm not sure this is possible 
with raw Planet2.  The Ruby community finally dealt with this by saving 
the full library dependency list in a file ("bundle", with version 
numbers) that you save alongside your app.  It works fairly well.


Their experience suggests that accidental backwards incompatible changes 
in libraries happen frequently enough to need some kind of support for.  
Compatibility with the core language was not supported.  Either a 
library's webpage would say "requires ruby core >= 1.8.x", or sometimes 
importing the library would produce an error message telling you the same.


Do these use cases make sense?  (I'd like to hear about library 
developer use cases, but I have no experience there)


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

Re: [racket-dev] planet2 and versions

[Asumu Takikawa]

On 2012-12-12 14:29:32 -0500, Ryan Culpepper wrote:
> I'm trying to understand how things are supposed to work in planet2
> without version information.

Maybe this was discussed in the other (quite long) thread about Planet
2, but another thing that the lack of versions makes difficult is having
both a development version of a package and a release version installed.

That is, I find it useful to develop a package with a local link (e.g.,
raco pkg install --link foo/). Eventually, I'll put up what I have on
the central server. If I understand how things now work correctly,
Planet 2 requires that I uninstall my local link and then install the
uploaded package (since they have conflicting collections).

If I subsequently work on my development version again, I have to
manually uninstall and re-install the package. Doing this dance
repeatedly is tedious.

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

Re: [racket-dev] scribble/doclang example?

[Matthew Flatt]

At Wed, 12 Dec 2012 18:45:10 -0700, Matthew Flatt wrote:
> It's backward-incompatible, but looking for existing uses of
> `scribble/doclang' [...]

Well, After sending my message, I remembered another place, and now I
think there may be more uses. So, I don't think a backward-incompatible
change is a good idea, after all.

I suggest that you pick a new name for the language that you'd like to
have, and fix the docs to talk about that one. Then, we can leave
`scribble/doclang' alone, documenting it as only for backward
compatibility.

> At Wed, 12 Dec 2012 17:29:19 -0700, Danny Yoo wrote:
> > I'm reading the documentation on how scribble/doclang works,
> > 
> >  http://docs.racket-lang.org/scribble/doclang.html
> > 
> > but it doesn't say really what it needs to work.
> > 
> > That is, a program written in scribble/doclang must provide a few
> > elements besides the chunks of document: it needs to also provide the
> > name of the id it's going to bind the document to, some function to
> > post-process after decoding, and some leading expressions.  I see that
> > other readers such as scribble/jfp take advantage of this to do extra
> > stuff.
> > 
> > 
> > Here's a small example I've ben able to figure out:
> > 
> > 
> > #lang racket
> > (module* example scribble/doclang
> >   doc
> >   values
> >   ()
> >   (require scribble/base)
> >   (provide (all-defined-out))
> >   (define foo (para "hello again"))
> >   "hello world, this is an example document"
> >   (para "note the " (bold "structure")))
> > 
> > (module+ main
> >   (require (submod ".." example))
> >   (printf "I see doc is: ~s\n\n" doc)
> >   (printf "I see foo is: ~s" foo))
> > 
> > 
> > and I was about to add this example to the doclang documentation, but
> > paused; the current interface seems awfully error-prone: it took me
> > several minutes to figure out why (module example scribble/doclang
> > "hello world") didn't work.
> > 
> > 
> > Would it acceptable if I hack up the language so that it takes those
> > three values as keyword arguments, and provide reasonable defaults?
> > 
> > 
> > That is, I'd like to be able to write:
> > 
> > 
> > (module example scribble/doclang
> >   "hello world, this is an example document")
> > 
> > 
> > and have it Just Work.
> > 
> > 
> > If we need to override the defaults, we should be able to provide them
> > as keywords at the beginning of the module:
> > 
> > 
> > (module example scribble/doclang
> >   #:id doc
> >   #:post-process values
> >   #:exprs ()
> > 
> >   "hello world, this is an example document")
> > 
> > 
> > 
> > Does that seem reasonable?
> > _
> >   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] scribble/doclang example?

[Matthew Flatt]

Yes, I think this is a good idea.

It's backward-incompatible, but looking for existing uses of
`scribble/doclang', I find only two uses not in the distribution: your
Planet package and the ICFP paper. The current `scribble/doclang' has
already drifted from the ICFP paper, and I imagine that you're willing
to adapt your Planet package. Given the small number of uses, plus the
fact that the documentation is some combination of non-existent and
incorrect (the docs say `#lang' instead of `require' for
`scribble/doclang'), I think it's probably ok.

At Wed, 12 Dec 2012 17:29:19 -0700, Danny Yoo wrote:
> I'm reading the documentation on how scribble/doclang works,
> 
>  http://docs.racket-lang.org/scribble/doclang.html
> 
> but it doesn't say really what it needs to work.
> 
> That is, a program written in scribble/doclang must provide a few
> elements besides the chunks of document: it needs to also provide the
> name of the id it's going to bind the document to, some function to
> post-process after decoding, and some leading expressions.  I see that
> other readers such as scribble/jfp take advantage of this to do extra
> stuff.
> 
> 
> Here's a small example I've ben able to figure out:
> 
> 
> #lang racket
> (module* example scribble/doclang
>   doc
>   values
>   ()
>   (require scribble/base)
>   (provide (all-defined-out))
>   (define foo (para "hello again"))
>   "hello world, this is an example document"
>   (para "note the " (bold "structure")))
> 
> (module+ main
>   (require (submod ".." example))
>   (printf "I see doc is: ~s\n\n" doc)
>   (printf "I see foo is: ~s" foo))
> 
> 
> and I was about to add this example to the doclang documentation, but
> paused; the current interface seems awfully error-prone: it took me
> several minutes to figure out why (module example scribble/doclang
> "hello world") didn't work.
> 
> 
> Would it acceptable if I hack up the language so that it takes those
> three values as keyword arguments, and provide reasonable defaults?
> 
> 
> That is, I'd like to be able to write:
> 
> 
> (module example scribble/doclang
>   "hello world, this is an example document")
> 
> 
> and have it Just Work.
> 
> 
> If we need to override the defaults, we should be able to provide them
> as keywords at the beginning of the module:
> 
> 
> (module example scribble/doclang
>   #:id doc
>   #:post-process values
>   #:exprs ()
> 
>   "hello world, this is an example document")
> 
> 
> 
> Does that seem reasonable?
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] scribble/doclang example?

[Danny Yoo]

I'm reading the documentation on how scribble/doclang works,

 http://docs.racket-lang.org/scribble/doclang.html

but it doesn't say really what it needs to work.

That is, a program written in scribble/doclang must provide a few
elements besides the chunks of document: it needs to also provide the
name of the id it's going to bind the document to, some function to
post-process after decoding, and some leading expressions.  I see that
other readers such as scribble/jfp take advantage of this to do extra
stuff.


Here's a small example I've ben able to figure out:


#lang racket
(module* example scribble/doclang
  doc
  values
  ()
  (require scribble/base)
  (provide (all-defined-out))
  (define foo (para "hello again"))
  "hello world, this is an example document"
  (para "note the " (bold "structure")))

(module+ main
  (require (submod ".." example))
  (printf "I see doc is: ~s\n\n" doc)
  (printf "I see foo is: ~s" foo))


and I was about to add this example to the doclang documentation, but
paused; the current interface seems awfully error-prone: it took me
several minutes to figure out why (module example scribble/doclang
"hello world") didn't work.


Would it acceptable if I hack up the language so that it takes those
three values as keyword arguments, and provide reasonable defaults?


That is, I'd like to be able to write:


(module example scribble/doclang
  "hello world, this is an example document")


and have it Just Work.


If we need to override the defaults, we should be able to provide them
as keywords at the beginning of the module:


(module example scribble/doclang
  #:id doc
  #:post-process values
  #:exprs ()

  "hello world, this is an example document")



Does that seem reasonable?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Ryan Culpepper]

On 12/12/2012 03:58 PM, Jay McCarthy wrote:

I agree with Carl.

But I would make an even stronger suggestion, I would suggest that you
completely drop support for old Racket versions and if necessary
release "webapis-lts" and "scriblogify-lts" packages that conflict
with "webapis" and can only work on old versions. The LTS ones
wouldn't be included in the DrDr-tested collection of packages, but
the others would be. Casual users should upgrade and users with
serious version problems should upgrade slowly with only the LTS
versions.


If I understand correctly, you are saying that non-LTS packages should 
ignore the recommendation of the FAQ (6.5, "package authors should not 
make backwards incompatible changes to packages").


That doesn't sound like a good solution.

If I want to support users running versions of Racket that are a couple 
releases old, it doesn't work.


If I want to depend on other packages, then in the absence of a standard 
approach I've got to trust that they have the same notions about 
compatibility and versions-encoded-as-package-names as I do. If I want 
to support Racket back to X.Y, I had better hope that the packages I 
depend on do too. That is, I'd have to figure out how each of them (and 
all of their dependencies) handle compatibility instead of just trusting 
that they all follow the single standard approach.


Finally, as a meta-point, is there any evidence that just throwing away 
versions will work? Any precedents? So far, this seems like a classic 
case of throwing the baby out with the bathwater: versions sometimes 
cause problems... so we won't have them. Now we have the same problems 
but fewer tools for handling them. (See also Eli's response.)


If planet2 is aimed at a problem that is restricted in scope somehow 
that it doesn't need to worry about version issues, I still don't 
understand what that narrower problem is. If I'm supposed to think about 
planet2 as a way of distributing code, I'm still confused about what my 
obligations are when I create a package and what I can rely on from 
other packages.


Ryan


I would also hope that P2's lack of an ability to depend on the core
version would induce better backwards and forwards compatibility from
Racket in the version.

But I'm a bit radical on this front, so I assume that we will have a
robust alternative based on Carl's idea that uses P2 underneath it.

Jay

On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund  wrote:

I believe it is by design that Planet 2 does not resolve this kind of issue.
This gives us room to experiment with different solutions without committing
to one up-front, since Planet 1 ran into various limitations of its built-in
policies.

I will propose one possible solution for your "webapis" example.  Distribute
a primary wrapper package called "webapis" and separate specific versions
such as "webapis1", "webapis2", and so forth.  Have the code in "webapis"
determine at compile-time which specific version of webapis is appropriate
for the current Racket version and install that package.  The specific
packages would contain the actual code a client would import.  That way,
installing the "webapis" package on any Racket version would install only
the version of the implementation that works.

I don't know if this is a complete solution, but it seems like a reasonable
starting point.  As we figure out what patterns work, they themselves can be
developed as reusable tools and built into their own packages.  I think this
room for improvement will make Planet 2 a much better long-term model than
Planet 1.  Of course we do eventually want a default system that package
developers can use without too much mucking about with "experimental"
versioning systems.  But I think an initial period of "crowd-sourcing" the
design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:


I'm trying to understand how things are supposed to work in planet2
without version information.

Let's say I release a package, "webapis". Time passes, and I notice that
Racket gets some cool new features (eg, better SSL support) that the
"webapis" package should use. I write the code, and ...

Do I release the new code under the same package name? If so, then the
package breaks for older versions of Racket, because IIUC planet2 has
nothing corresponding to planet1's 'required-core-version field. And there
doesn't seem to be a way to tell Racket "no, sorry, go back to the older
version of the package". (Rather, there's no way for a client to do so. The
fix would be for the package maintainer to release an "upgrade" that reverts
to the old code.) So it seems like it would be really bad for me to release
the new code under the name "webapis".

In other words, if a package changes its dependencies, that's an
incompatible change for the package, and it needs a new name. Right?

Suppose I release the new code as "webapis2". And suppose there's another
package (let's call it "scr

Re: [racket-dev] planet2 and versions

[Eli Barzilay]

On Dec 12, 2012 3:14 PM, "Carl Eastlund"  wrote:
>
> I will propose one possible solution for your "webapis" example.
Distribute a primary wrapper package called "webapis" and separate specific
versions such as "webapis1", "webapis2", and so forth.  Have the code in
"webapis" determine at compile-time which specific version of webapis is
appropriate for the current Racket version and install that package.  The
specific packages would contain the actual code a client would import.
That way, installing the "webapis" package on any Racket version would
install only the version of the implementation that works.

IMO, the fact that such workarounds are already suggested at this early
stage is what makes this a bad idea.  AFAICT, the only positive point is to
experiment with things to come up with something that works, but why is
that needed?  I still believe that the main principle should be to make it
as boring and as conventional as possible, and pretty much all package
systems have the ability to specify required versions, no need for the
multiple version fanciness.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Ryan Culpepper]

On 12/12/2012 03:13 PM, Carl Eastlund wrote:

I believe it is by design that Planet 2 does not resolve this kind of
issue.  This gives us room to experiment with different solutions
without committing to one up-front, since Planet 1 ran into various
limitations of its built-in policies.

I will propose one possible solution for your "webapis" example.
Distribute a primary wrapper package called "webapis" and separate
specific versions such as "webapis1", "webapis2", and so forth.  Have
the code in "webapis" determine at compile-time which specific version
of webapis is appropriate for the current Racket version and install
that package.  The specific packages would contain the actual code a
client would import.  That way, installing the "webapis" package on any
Racket version would install only the version of the implementation that
works.


IIUC, a package's dependencies are fixed at package creation time; they 
can't be adjusted at compile time. (Well, now that the dependencies are 
specified via an expression in a #lang setup/infotab file, maybe it's 
possible to adjust them at compile time... or maybe installation time? 
But there's still no access to the Racket version, although there's 
access to other things)


Ryan



I don't know if this is a complete solution, but it seems like a
reasonable starting point.  As we figure out what patterns work, they
themselves can be developed as reusable tools and built into their own
packages.  I think this room for improvement will make Planet 2 a much
better long-term model than Planet 1.  Of course we do eventually want a
default system that package developers can use without too much mucking
about with "experimental" versioning systems.  But I think an initial
period of "crowd-sourcing" the design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper mailto:r...@cs.utah.edu>> wrote:

I'm trying to understand how things are supposed to work in planet2
without version information.

Let's say I release a package, "webapis". Time passes, and I notice
that Racket gets some cool new features (eg, better SSL support)
that the "webapis" package should use. I write the code, and ...

Do I release the new code under the same package name? If so, then
the package breaks for older versions of Racket, because IIUC
planet2 has nothing corresponding to planet1's
'required-core-version field. And there doesn't seem to be a way to
tell Racket "no, sorry, go back to the older version of the
package". (Rather, there's no way for a client to do so. The fix
would be for the package maintainer to release an "upgrade" that
reverts to the old code.) So it seems like it would be really bad
for me to release the new code under the name "webapis".

In other words, if a package changes its dependencies, that's an
incompatible change for the package, and it needs a new name. Right?

Suppose I release the new code as "webapis2". And suppose there's
another package (let's call it "scriblogify") that depends on
"webapis". If that code wants to use "webapis2", that's a dependency
change, so it would have to be released as "scriblogify2". There's
no way to express "link me with the most recent compatible version
of webapis*", right?

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




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

Re: [racket-dev] planet2 and versions

[Jay McCarthy]

I agree with Carl.

But I would make an even stronger suggestion, I would suggest that you
completely drop support for old Racket versions and if necessary
release "webapis-lts" and "scriblogify-lts" packages that conflict
with "webapis" and can only work on old versions. The LTS ones
wouldn't be included in the DrDr-tested collection of packages, but
the others would be. Casual users should upgrade and users with
serious version problems should upgrade slowly with only the LTS
versions.

I would also hope that P2's lack of an ability to depend on the core
version would induce better backwards and forwards compatibility from
Racket in the version.

But I'm a bit radical on this front, so I assume that we will have a
robust alternative based on Carl's idea that uses P2 underneath it.

Jay

On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund  wrote:
> I believe it is by design that Planet 2 does not resolve this kind of issue.
> This gives us room to experiment with different solutions without committing
> to one up-front, since Planet 1 ran into various limitations of its built-in
> policies.
>
> I will propose one possible solution for your "webapis" example.  Distribute
> a primary wrapper package called "webapis" and separate specific versions
> such as "webapis1", "webapis2", and so forth.  Have the code in "webapis"
> determine at compile-time which specific version of webapis is appropriate
> for the current Racket version and install that package.  The specific
> packages would contain the actual code a client would import.  That way,
> installing the "webapis" package on any Racket version would install only
> the version of the implementation that works.
>
> I don't know if this is a complete solution, but it seems like a reasonable
> starting point.  As we figure out what patterns work, they themselves can be
> developed as reusable tools and built into their own packages.  I think this
> room for improvement will make Planet 2 a much better long-term model than
> Planet 1.  Of course we do eventually want a default system that package
> developers can use without too much mucking about with "experimental"
> versioning systems.  But I think an initial period of "crowd-sourcing" the
> design of that system will do us some good.
>
> Carl Eastlund
>
>
>
> On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:
>>
>> I'm trying to understand how things are supposed to work in planet2
>> without version information.
>>
>> Let's say I release a package, "webapis". Time passes, and I notice that
>> Racket gets some cool new features (eg, better SSL support) that the
>> "webapis" package should use. I write the code, and ...
>>
>> Do I release the new code under the same package name? If so, then the
>> package breaks for older versions of Racket, because IIUC planet2 has
>> nothing corresponding to planet1's 'required-core-version field. And there
>> doesn't seem to be a way to tell Racket "no, sorry, go back to the older
>> version of the package". (Rather, there's no way for a client to do so. The
>> fix would be for the package maintainer to release an "upgrade" that reverts
>> to the old code.) So it seems like it would be really bad for me to release
>> the new code under the name "webapis".
>>
>> In other words, if a package changes its dependencies, that's an
>> incompatible change for the package, and it needs a new name. Right?
>>
>> Suppose I release the new code as "webapis2". And suppose there's another
>> package (let's call it "scriblogify") that depends on "webapis". If that
>> code wants to use "webapis2", that's a dependency change, so it would have
>> to be released as "scriblogify2". There's no way to express "link me with
>> the most recent compatible version of webapis*", right?
>>
>> Ryan
>> _
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev
>>
>
>
> _
>   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

Re: [racket-dev] planet2 and versions

[Carl Eastlund]

I believe it is by design that Planet 2 does not resolve this kind of
issue.  This gives us room to experiment with different solutions without
committing to one up-front, since Planet 1 ran into various limitations of
its built-in policies.

I will propose one possible solution for your "webapis" example.
Distribute a primary wrapper package called "webapis" and separate specific
versions such as "webapis1", "webapis2", and so forth.  Have the code in
"webapis" determine at compile-time which specific version of webapis is
appropriate for the current Racket version and install that package.  The
specific packages would contain the actual code a client would import.
That way, installing the "webapis" package on any Racket version would
install only the version of the implementation that works.

I don't know if this is a complete solution, but it seems like a reasonable
starting point.  As we figure out what patterns work, they themselves can
be developed as reusable tools and built into their own packages.  I think
this room for improvement will make Planet 2 a much better long-term model
than Planet 1.  Of course we do eventually want a default system that
package developers can use without too much mucking about with
"experimental" versioning systems.  But I think an initial period of
"crowd-sourcing" the design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:

> I'm trying to understand how things are supposed to work in planet2
> without version information.
>
> Let's say I release a package, "webapis". Time passes, and I notice that
> Racket gets some cool new features (eg, better SSL support) that the
> "webapis" package should use. I write the code, and ...
>
> Do I release the new code under the same package name? If so, then the
> package breaks for older versions of Racket, because IIUC planet2 has
> nothing corresponding to planet1's 'required-core-version field. And there
> doesn't seem to be a way to tell Racket "no, sorry, go back to the older
> version of the package". (Rather, there's no way for a client to do so. The
> fix would be for the package maintainer to release an "upgrade" that
> reverts to the old code.) So it seems like it would be really bad for me to
> release the new code under the name "webapis".
>
> In other words, if a package changes its dependencies, that's an
> incompatible change for the package, and it needs a new name. Right?
>
> Suppose I release the new code as "webapis2". And suppose there's another
> package (let's call it "scriblogify") that depends on "webapis". If that
> code wants to use "webapis2", that's a dependency change, so it would have
> to be released as "scriblogify2". There's no way to express "link me with
> the most recent compatible version of webapis*", right?
>
> Ryan
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] planet2 and versions

[Ryan Culpepper]

I'm trying to understand how things are supposed to work in planet2 
without version information.


Let's say I release a package, "webapis". Time passes, and I notice that 
Racket gets some cool new features (eg, better SSL support) that the 
"webapis" package should use. I write the code, and ...


Do I release the new code under the same package name? If so, then the 
package breaks for older versions of Racket, because IIUC planet2 has 
nothing corresponding to planet1's 'required-core-version field. And 
there doesn't seem to be a way to tell Racket "no, sorry, go back to the 
older version of the package". (Rather, there's no way for a client to 
do so. The fix would be for the package maintainer to release an 
"upgrade" that reverts to the old code.) So it seems like it would be 
really bad for me to release the new code under the name "webapis".


In other words, if a package changes its dependencies, that's an 
incompatible change for the package, and it needs a new name. Right?


Suppose I release the new code as "webapis2". And suppose there's 
another package (let's call it "scriblogify") that depends on "webapis". 
If that code wants to use "webapis2", that's a dependency change, so it 
would have to be released as "scriblogify2". There's no way to express 
"link me with the most recent compatible version of webapis*", right?


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

Re: [racket-dev] [DrDr] R25887 (timeout 1) (unclean 1) (stderr 1) (changes 64)

[Jay McCarthy]

On Wed, Dec 12, 2012 at 11:51 AM, Sam Tobin-Hochstadt  wrote:
> On Wed, Dec 12, 2012 at 1:44 PM, Jay McCarthy  wrote:
>> On Tue, Dec 11, 2012 at 1:01 PM, Sam Tobin-Hochstadt  
>> wrote:
>>> The Typed Racket optimizer tests continue to fail on an intermittent
>>> basis in DrDr, as shown below.  I'd really like to fix this,
>>> especially since we're doing very well for zero failures on DrDr, but
>>> I don't know what's going wrong.
>>>
>>> The error is:
>>>
>>> force: promise's thread terminated without result or exception
>>>   promise: #
>>>   context...:
>>>/opt/plt/builds//trunk/collects/racket/promise.rkt:98:2
>>>
>>> /opt/plt/builds//trunk/collects/tests/typed-racket/optimizer/run.rkt:50:3:
>>> for-loop
>>>
>>> /opt/plt/builds//trunk/collects/tests/typed-racket/optimizer/run.rkt:44:0:
>>> mk-suite
>>>
>>> which I think indicates that a thread is being killed somewhere, but I
>>> don't know why that would be happening, and I haven't seen this
>>> happening on other machines.
>>>
>>> Are there any techniques recommending for finding what's killing this
>>> thread?  Does DrDr do anything special that would affect this?  The
>>> relevant code is here:
>>> https://github.com/plt/racket/blob/master/collects/tests/typed-racket/optimizer/run.rkt#L44-53
>>
>> There are two cases were DrDr kills stuff. Case 1 is when there's a
>> timeout, but you aren't close to that. Case 2 is when DrDr itself
>> crashes and needs to get a clean slate of system resources. I think
>> this is unlikely to be the problem, because the DrDr instance that
>> crashed would be the one listening to the test's output not the one
>> that did the killing. But I can look into it.
>
> Given that this happens quite regularly (maybe 1 in 5 runs) I'd be
> surprised if DrDr itself crashed that often.  Is that likely?

DrDr crashes very often, almost every push. This is mainly because the
X setup I use is unreliable, crashes, and then I have to tear down all
of DrDr to get back to a consistent state. DrDr is designed around
crashing often as a way of dealing with this problem (and a few other
similar ones.)

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] [DrDr] R25887 (timeout 1) (unclean 1) (stderr 1) (changes 64)

[Asumu Takikawa]

On 2012-12-12 13:54:14 -0500, Asumu Takikawa wrote:
> FWIW, I get this intermittently when I run the Racket tests.

Clarification: I meant the TR tests.

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

Re: [racket-dev] [DrDr] R25887 (timeout 1) (unclean 1) (stderr 1) (changes 64)

[Asumu Takikawa]

On 2012-12-11 15:01:42 -0500, Sam Tobin-Hochstadt wrote:
> which I think indicates that a thread is being killed somewhere, but I
> don't know why that would be happening, and I haven't seen this
> happening on other machines.

FWIW, I get this intermittently when I run the Racket tests.

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

Re: [racket-dev] [DrDr] R25887 (timeout 1) (unclean 1) (stderr 1) (changes 64)

[Sam Tobin-Hochstadt]

On Wed, Dec 12, 2012 at 1:44 PM, Jay McCarthy  wrote:
> On Tue, Dec 11, 2012 at 1:01 PM, Sam Tobin-Hochstadt  
> wrote:
>> The Typed Racket optimizer tests continue to fail on an intermittent
>> basis in DrDr, as shown below.  I'd really like to fix this,
>> especially since we're doing very well for zero failures on DrDr, but
>> I don't know what's going wrong.
>>
>> The error is:
>>
>> force: promise's thread terminated without result or exception
>>   promise: #
>>   context...:
>>/opt/plt/builds//trunk/collects/racket/promise.rkt:98:2
>>
>> /opt/plt/builds//trunk/collects/tests/typed-racket/optimizer/run.rkt:50:3:
>> for-loop
>>
>> /opt/plt/builds//trunk/collects/tests/typed-racket/optimizer/run.rkt:44:0:
>> mk-suite
>>
>> which I think indicates that a thread is being killed somewhere, but I
>> don't know why that would be happening, and I haven't seen this
>> happening on other machines.
>>
>> Are there any techniques recommending for finding what's killing this
>> thread?  Does DrDr do anything special that would affect this?  The
>> relevant code is here:
>> https://github.com/plt/racket/blob/master/collects/tests/typed-racket/optimizer/run.rkt#L44-53
>
> There are two cases were DrDr kills stuff. Case 1 is when there's a
> timeout, but you aren't close to that. Case 2 is when DrDr itself
> crashes and needs to get a clean slate of system resources. I think
> this is unlikely to be the problem, because the DrDr instance that
> crashed would be the one listening to the test's output not the one
> that did the killing. But I can look into it.

Given that this happens quite regularly (maybe 1 in 5 runs) I'd be
surprised if DrDr itself crashed that often.  Is that likely?

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

Re: [racket-dev] [DrDr] R25887 (timeout 1) (unclean 1) (stderr 1) (changes 64)

[Jay McCarthy]

On Tue, Dec 11, 2012 at 1:01 PM, Sam Tobin-Hochstadt  wrote:
> The Typed Racket optimizer tests continue to fail on an intermittent
> basis in DrDr, as shown below.  I'd really like to fix this,
> especially since we're doing very well for zero failures on DrDr, but
> I don't know what's going wrong.
>
> The error is:
>
> force: promise's thread terminated without result or exception
>   promise: #
>   context...:
>/opt/plt/builds//trunk/collects/racket/promise.rkt:98:2
>
> /opt/plt/builds//trunk/collects/tests/typed-racket/optimizer/run.rkt:50:3:
> for-loop
>
> /opt/plt/builds//trunk/collects/tests/typed-racket/optimizer/run.rkt:44:0:
> mk-suite
>
> which I think indicates that a thread is being killed somewhere, but I
> don't know why that would be happening, and I haven't seen this
> happening on other machines.
>
> Are there any techniques recommending for finding what's killing this
> thread?  Does DrDr do anything special that would affect this?  The
> relevant code is here:
> https://github.com/plt/racket/blob/master/collects/tests/typed-racket/optimizer/run.rkt#L44-53

There are two cases were DrDr kills stuff. Case 1 is when there's a
timeout, but you aren't close to that. Case 2 is when DrDr itself
crashes and needs to get a clean slate of system resources. I think
this is unlikely to be the problem, because the DrDr instance that
crashed would be the one listening to the test's output not the one
that did the killing. But I can look into it.

Jay

>
> Sam
>
> On Tue, Dec 11, 2012 at 1:46 PM,   wrote:
>> DrDr has finished building push #25887 after 58.56m.
>>
>> http://drdr.racket-lang.org/25887/
>>
>> A file you are responsible for has a condition that may need inspecting.
>>   unclean:
>> http://drdr.racket-lang.org/25887/collects/tests/typed-racket/run.rkt
>>
>>   stderr:
>> http://drdr.racket-lang.org/25887/collects/tests/typed-racket/run.rkt
>>
>>



--
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] Planet 2 default package name services

[Jay McCarthy]

Yes, that's part of the transition plan. Right now is not an opportune
time for me to do it because of finals, etc. But I anticipate to get
it ready for Eli to make the necessary redirects by Christmas.

Jay

On Wed, Dec 12, 2012 at 10:57 AM, Carl Eastlund  wrote:
> The default Planet 2 package name services are URLs based on
> plt-etc.byu.edu.  While I understand why Planet 2 is hosted there -- all of
> Racket is at one university or another -- wouldn't a racket-lang.org URL be
> better, and then redirect to *.byu.edu behind the scenes?  Like
> planet2.racket-lang.org for plt-etc.byu.edu:9003 and
> legacy.planet2.racket-lang.org for ...:9004, or something like that?  That
> would be more intuitive for anyone looking at the URLs, and flexible in case
> we decide to move the hosting at a later date.
>
> Carl Eastlund
>



-- 
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-dev] Planet 2 default package name services

[Carl Eastlund]

The default Planet 2 package name services are URLs based on plt-etc.byu.edu.
While I understand why Planet 2 is hosted there -- all of Racket is at one
university or another -- wouldn't a racket-lang.org URL be better, and then
redirect to *.byu.edu behind the scenes?  Like planet2.racket-lang.org for
plt-etc.byu.edu:9003 and legacy.planet2.racket-lang.org for ...:9004, or
something like that?  That would be more intuitive for anyone looking at
the URLs, and flexible in case we decide to move the hosting at a later
date.

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