Re: [racket-users] Re: Package layout in docs

2017-02-07 Thread Ethan Estrada
On Mon, Jan 30, 2017 at 3:33 PM, Leif Andersen wrote: > > So, I really don't care how it work. Logo is fine, seperate website is > fine. Checkboxes that lets users say what packages come in are fine. > Yelp reviews are fine (although if we go down that route can we also >

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Ethan Estrada
On Mon, Jan 30, 2017 at 6:17 PM, Hendrik Boom wrote: > While we were talking about "core" and non-"core"packages, there was > controversy. Now that we have changed words, and are talking about > "rings", we seem to be happier. What a difference a word makes! Or > is

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Neil Van Dyke
Jack Firth wrote on 01/31/2017 03:11 PM: If the package build server and catalog hosted built packages for multiple Racket versions, I think we could go a long ways towards removing the need to split packages completely. If there's important requirements driving that, and if that's a good

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Jack Firth
On Tuesday, January 31, 2017 at 11:25:31 AM UTC-8, Neil Van Dyke wrote: > For the benefit of the tightwad people, packages could optionally > include metadata about any docs and tests that can be stripped -- > anything nonessential to "run-only" the package. This metadata could be > used by

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Neil Van Dyke
Greg Trzeciak wrote on 01/31/2017 01:24 PM: Speaking of packages - there seems to be a trend recently in racket packages to create separate packages for main, lib, doc, test, etc. This causes an artificial inflation in available packages and IMHO may cause some confusion for newcomers as

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Greg Trzeciak
On Tuesday, January 31, 2017 at 7:29:44 PM UTC+1, Jay McCarthy wrote: > I think it would be nice to change the frontend to collapse them > together in some meaningful way to help read the catalog. > > Jay +1 That would solve the issue. -- You received this message because you are subscribed to

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Jay McCarthy
I think it would be nice to change the frontend to collapse them together in some meaningful way to help read the catalog. Jay On Tue, Jan 31, 2017 at 1:29 PM, Jay McCarthy wrote: > On Tue, Jan 31, 2017 at 1:24 PM, Greg Trzeciak wrote: >> Other than

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Jay McCarthy
On Tue, Jan 31, 2017 at 1:24 PM, Greg Trzeciak wrote: > Other than package creator's convenience - is their any rationale for this > trend I don't see? Actually, it is INCONVENIENT for the creator. It provides to the users the ability to install the library without docs

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Jay McCarthy
On Mon, Jan 30, 2017 at 6:17 PM, Hendrik Boom wrote: > While we were talking about "core" and non-"core"packages, there was > controversy. Now that we have changed words, and are talking about > "rings", we seem to be happier. What a difference a word makes! Or > is

Re: [racket-users] Re: Package layout in docs

2017-01-31 Thread Hendrik Boom
On Tue, Jan 31, 2017 at 01:37:41PM +0800, WarGrey Gyoudmon Ju wrote: > Hello. > > This is one of the culture shocks that a new Racketeer would face, and so > was I. > But this statement makes it clear to me: Racket is an operating system that > pretend to a programming language; Much like emacs,

Re: [racket-users] Re: Package layout in docs

2017-01-30 Thread WarGrey Gyoudmon Ju
Hello. This is one of the culture shocks that a new Racketeer would face, and so was I. But this statement makes it clear to me: Racket is an operating system that pretend to a programming language; Yes, it may totally be a kind of over reading here. Say, I do not care if a manual page is the

Re: [racket-users] Re: Package layout in docs

2017-01-30 Thread Philip McGrath
I was also going to suggest the ring system as a way of giving more information without imposing an unnecessary artificial distinction. In general I'm enthusiastic about the benefits of not having a sharp dividing line, but it would be useful to show more clearly in the documentation which