Re: [racket-dev] proposal for moving to packages
On Mon, May 20, 2013 at 2:23 PM, Jose A. Ortega Ruiz wrote: > Here's hope that down the line there'll be binary+source packages that > end users can install with the same ease as today. Matthew's email mentioned this a little, but the plan is that: $ raco pkg install drracket will install source as well as binaries. The big change is that the distribution you get from http://racket-lang.org/download/ won't include all of that stuff. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
I've been using using Racket (and DrRacket) to teach programming to architecture students. These are not sophisticated users, so any move that makes it more difficult for them to use Racket is not good news. What happened to the "batteries included" motto? Just my 0.1 cents. Best, António. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
I'm not sure I follow on why binary packages make it easier to reduce dependencies between packages, or why binary packages offer faster installs. I'm guessing that binary packages prevent cyclic dependencies between packages, but it seems like there are many other options that still get this side effect. Such as explicit checks when building the package. For faster installs, the only benefit I see of binary packages over precompiled source packages is a small savings in size which doesn't seem like it would amount to much of the install time. Can someone explain the claims for binary packages? On Mon, May 20, 2013 at 8:57 PM, Jon Zeppieri wrote: > On Mon, May 20, 2013 at 10:04 PM, Neil Van Dyke wrote: >> [snip] >> >> Example: Imagine I'm in the middle of writing a Racket program and am >> wondering about characteristics of some kind of I/O port in Racket. With >> transparent source accessibility, I can just click on an identifier in my >> program in DrRacket to start browsing the implementation. Maybe I see a >> possible improvement, or seeing the source pre-empts yet another email list >> question that otherwise only Matthew could answer, or I feel empowered to go >> add a new feature. If the source is not as accessible, then I'm more likely >> to be a mere naive user of the tools, rather than to understand the tools >> and help improve them. >> > > +inf.0 > > Though the easiest way to make the source available is just to keep it > in the distribution. I'll be sad to see it go. > > -Jon > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On Mon, May 20, 2013 at 10:04 PM, Neil Van Dyke wrote: > [snip] > > Example: Imagine I'm in the middle of writing a Racket program and am > wondering about characteristics of some kind of I/O port in Racket. With > transparent source accessibility, I can just click on an identifier in my > program in DrRacket to start browsing the implementation. Maybe I see a > possible improvement, or seeing the source pre-empts yet another email list > question that otherwise only Matthew could answer, or I feel empowered to go > add a new feature. If the source is not as accessible, then I'm more likely > to be a mere naive user of the tools, rather than to understand the tools > and help improve them. > +inf.0 Though the easiest way to make the source available is just to keep it in the distribution. I'll be sad to see it go. -Jon _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
Juan Francisco Cantero Hurtado wrote at 05/20/2013 11:20 PM: I also think that git submodules are a bad idea for packages. One git repo per package is more simple and less problematic. Do people expect to often do commits involving changes across these package boundaries? If so, would another option be to keep a single repo, not use these Git submodules, and just have Racket translate the Git paths behind-the-scenes for packages coming from this core Racket repo? Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On 05/20/13 23:24, Carl Eastlund wrote: On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa wrote: On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote: Eventually, when the dust settles, I think we'll want to convert every directory to its own git repo, and then we can incorporate the individual repos as git submodules. One nice thing about the current repo organization is that push notifications for every part of the PLT codebase go to all of the developers. Will that still be available in this organization scheme? (I don't care if it's opt-in too much, but opt-out will hopefully mean more eyes see the code) Cheers, Asumu Overall, I'm really glad to see Racket moving into the package system. I think it will be good for both (the Racket core and the package system). I'd like to mention, though, that git submodules can be a real pain for synchronizing development of multiple repositories. They seem to have been designed primarily for importing upstream repositories, rather than for multiple "peer" repositories. I'm not much more fond of the alternatives I have tried, either; if we're committing to splitting Racket into multiple repositories as well as multiple packages, we should be aware there may be another minor git learning curve ahead. Thanks to Jay and Matthew for working on all of this! I also think that git submodules are a bad idea for packages. One git repo per package is more simple and less problematic. Thanks for the hard work :) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
I'm calling for making Racket and package source transparently accessible, even though not actually bundled into distribution downloads... Racket has a research and education bent, and also attracts some of the more sophisticated developers. For all of these audiences, there's a tradition of accessibility of source, and arguably value in that. I think transparent navigability to source would be appropriate for Racket. Transparent navigability to source could mean that DrRacket will download source on-demand for any binary package that is installed, rather than source having to be bundled with the package, or requiring user to go get source separately. Admittedly, I think source accessibility is not as important in Racket as in Emacs. (Because, for general programming, the Racket documentation is sufficient and the source wouldn't help. And for extension of the programming environment, which was one of Emacs's greatest achievements, extending DrRacket is much harder; plus, the DrRacket source is not much help if you didn't previously tackle the manuals on frameworks and such, which almost no one does.) But there are uses for source accessibility, especially for independent add-on packages, and the principle of being able to easily pop the hood still has value. Example: Imagine I'm in the middle of writing a Racket program and am wondering about characteristics of some kind of I/O port in Racket. With transparent source accessibility, I can just click on an identifier in my program in DrRacket to start browsing the implementation. Maybe I see a possible improvement, or seeing the source pre-empts yet another email list question that otherwise only Matthew could answer, or I feel empowered to go add a new feature. If the source is not as accessible, then I'm more likely to be a mere naive user of the tools, rather than to understand the tools and help improve them. Side note: I'm also looking forward to seeing how this new packaging works out, especially if it leads to me being able to ship small binary packages for iPhone/Mac/Windows, implemented in Racket. (I don't care about open source principles on those very closed platforms; I just want their money. Which is totally different from what I want from an intellectually-inclined open source development platform.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] tcp_listen error handling
Hi. I've successfully started Racket 5.3.4.7 with Geiser server through JNI +
SDL2 on Android (and this combination mostly works with small hacks), but got
some issues due to racket's implementation. This is last one I'm trying to
understand. What should be here instead of the "address" expression?
2349} else {
2350 scheme_raise_exn(MZEXN_FAIL_NETWORK,
2351 "tcp-listen: host not found\n"
2352 " address: %s\n"
2353 " system error: %N",
2354 address, 1, err);
2355 return NULL;
2356}
2357 }
https://github.com/plt/racket/blob/master/src/racket/src/network.c#L2354
It looks like there should be (but i'm not sure)
address ? address : "#f" // as i see at another place, because it's possible
to have NULL according to the:
https://github.com/plt/racket/blob/master/src/racket/src/network.c#L2147
Without such change I got segfault because sch_vsprintf tried to process NULL
pointer, when i forgot to grant internet permissions for my application and
tried to call start-geiser function (getaddrinfo returns fail in this situation
and this `else` block is called).
--
Alex Moiseenko
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages: repository
At Mon, 20 May 2013 18:27:34 -0400, Eli Barzilay wrote: > An hour and a half ago, Matthew Flatt wrote: > > This plan has two prominent implications: > > > > * The current git repo's directory structure will change. [...] > > I very strongly object to this. While in theory git will follow > everything, this requires doing some more work which most people won't > know about, so a result of all of this is going to be loss of > historical information. So I think that it's much better to move > directly to several repositories (IIUC, one repository for each > suggested toplevbel directory). > > The only goal of the intermediate state seems to be providing some > gradual change before switching to submodules -- and on one hand, I > think that the new layout will force people to learn how to deal with > it, and on the other, it'll make people spend work twice, once on the > layout change and again on the switch to modules. > > So assuming that a gradual change is the goal, I think that there are > better ways to do that. It's about a kind of gradual change, but not quite so gradual. I would like to switch immediately to a package-oriented view of Racket, instead of thinking about packages as something that you get by squinting at our current tree. Concretely, new repositories that are just a subset of the current repo would be off-by-one in directory structure compared to a normal package. Each package should correspond to a subtree starting from the "collects" level, not the parent of "collects". We could massage the two views into one, but I'd rather not. At the time time, I agree that it's tricky to properly extract history for the new repositories, and there will be many issues in dealing with multiple repositories (e.g., submodules may not be the way to go). So, I'd like to delay that part until a second step. To put it another way and overstate a little: I'm trying to get buy-in from dev to make the switch to packages wholesale. The little bit of staging in the plan is to make the conversion itself easier, and not to simplify the switch for developers. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
Well, ideally there would be some new module-name->source function that could return URIs like http://path/to/file.rkt (or for that matter, file:///path/to/file.rkt), based on info.rkt for packages? Given that piece, a couple ways to do it -- favoring doing it more in Emacs vs. more in Racket -- but both involve having a local cache, and also using If-Modified-Since request headers? Maybe even the ability to "prefill the cache and never expire it" ... which seems awfully like source installation by other means? p.s. An approach favoring doing it more on the Racket side than on the Emacs side, could also support FRs like one I saw on the main list recently, which is that File | Open in DrRacket should be able to open remote files. That was for a classroom setting IIRC. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages: repository
An hour and a half ago, Matthew Flatt wrote:
> I used to think that we'd take advantage of the package manager by
> gradually pulling parts out of the Racket git repo and making them
> packages.
(Generally, +1. I'll reply just on the repository point here.)
> This plan has two prominent implications:
>
> * The current git repo's directory structure will change. [...]
I very strongly object to this. While in theory git will follow
everything, this requires doing some more work which most people won't
know about, so a result of all of this is going to be loss of
historical information. So I think that it's much better to move
directly to several repositories (IIUC, one repository for each
suggested toplevbel directory).
The only goal of the intermediate state seems to be providing some
gradual change before switching to submodules -- and on one hand, I
think that the new layout will force people to learn how to deal with
it, and on the other, it'll make people spend work twice, once on the
layout change and again on the switch to modules.
So assuming that a gradual change is the goal, I think that there are
better ways to do that. Here's a suggestion:
* The main repository is split into the different repositories.
Initially, this is done without any consideration for submodules,
with the idea of having "advanced gitters" come up with their own
solutions.
* However, don't remove the main repository, just keep it as an
aggregate of the content that is found in the split repositories.
If the structure is going to be the same in all of them (ie, the
same directories and files are in all as they are now in the
single repository), then pulling changes from the new repos to the
main one is going to be trivial to the point of being automated.
* The new repos will not get mirrored on github. This is because
github repos come with a bunch of functionality that is best kept
in a single place -- like wiki pages and issues. (But see below.)
* So the only difference would be for people who commit work to the
main repo. This can be done in various ways, depending on the
developers who do these commits:
- Advanced developers would have all of the repos and will push
directly to them. This group of people is likely to start
small, and evenetually have all of the core committers in it.
("Core" as in the people who push to the plt repo now.) As I
said above, this will likely involve some experimentation for
these people, which will later get translated into easy setups
that will allow more people to switch to it.
- "Outsiders" can continue to work as usual: fork the main plt
repo (mostly on github) and send pull requests. The pull
request will then be pushed by a core committer as it is done
now, where the core committer pushes to the actual relevant
repo, and that eventually propagates back to the main repo so
that the contributor sees that the work was merged. The merging
should usually be trivial, except in extremely rare cases where
the push touches on files from different new repos. In these
cases it should be possible to either split the commit into
different ones for the different repos, or ask the contributor
to split the commit to different ones for the different files.
- The only people left are core committers who will work with the
main repository. I can see a bunch of ways to deal with this.
First, the commit can be sent as a pull request to one of the
advanced gitters who will then do it for the actual repository.
This is easier than it sounds: git has a bunch of commands to do
this, and for all practical purposes, you'd just replace the
"git push" part of your workflow with "git send-email". I
*think* (but I'm not 100% sure) that this work can be automated
too, so it's fine if I (or some other excited soul) gets these
emails and merges them.
There is an inconvenience point here: once you send a pull
request and its merged, the actual commits that are merged (to
the main repo, which you're using if you're in this group) are
different objects. This is nothing new -- it's something that
people who do all contibutions via pull requests deal with,
since we have a policy of rebasing rather than merging.
Usually, when you pull from the update repo, git should notice
that your changes are already there. (At least I hope it does.)
Things will be less convenient for people who use git more
intensly: if you have lots of branches etc. But I think that
such people really should just move to the first group sooner...
* This stage can go on for a while, as the code & machinery involved
evolves to a point of being smooth enough. By smooth, I mean that
- it be easy enough to build the whole thing as you d
Re: [racket-dev] proposal for moving to packages
On Mon, May 20 2013, Matthew Flatt wrote: [...] > Some drawbacks to omitting source are immediately apparent: > > - Users will be less able to make source changes on their systems to >help us debug. > >Having the binary form of a package installed does not preclude >"upgrading" to a source package. So, we could ask a user to use the >package manager to install the source form of, say, the "drracket" >package, and then try out a change. In that way, users can still >help, but it will be less convenient. > > - Users will be less able to read installed code as examples. > >Our source code is now easily available via the web interfaces at >http://git.racket-lang.org/ and GitHub, so users can always look >there, instead. FWIW (and i know it's not much, but anyway), this will be a big loss for Geiser users, who right know can jump to any core function source with a single keystroke and without leaving the editor. IME, there's a huge difference between that and having to switch to a web browser to find it, both when learning or programming new applications. Here's hope that down the line there'll be binary+source packages that end users can install with the same ease as today. Cheers, jao -- Nostalgia isn’t what it used to be. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa wrote: > On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote: > > Eventually, when the dust settles, I think we'll want to convert every > > directory to its own git repo, and then we can incorporate the > > individual repos as git submodules. > > One nice thing about the current repo organization is that push > notifications for every part of the PLT codebase go to all of the > developers. > > Will that still be available in this organization scheme? (I don't care > if it's opt-in too much, but opt-out will hopefully mean more eyes see > the code) > > Cheers, > Asumu > Overall, I'm really glad to see Racket moving into the package system. I think it will be good for both (the Racket core and the package system). I'd like to mention, though, that git submodules can be a real pain for synchronizing development of multiple repositories. They seem to have been designed primarily for importing upstream repositories, rather than for multiple "peer" repositories. I'm not much more fond of the alternatives I have tried, either; if we're committing to splitting Racket into multiple repositories as well as multiple packages, we should be aware there may be another minor git learning curve ahead. Thanks to Jay and Matthew for working on all of this! --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote: > Eventually, when the dust settles, I think we'll want to convert every > directory to its own git repo, and then we can incorporate the > individual repos as git submodules. One nice thing about the current repo organization is that push notifications for every part of the PLT codebase go to all of the developers. Will that still be available in this organization scheme? (I don't care if it's opt-in too much, but opt-out will hopefully mean more eyes see the code) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] proposal for moving to packages
I used to think that we'd take advantage of the package manager by gradually pulling parts out of the Racket git repo and making them packages. Now, I think we should just shift directly to a small-ish Racket core, making everything else a package immediately. "Core" means enough to run `raco pkg'. A key point to remember is that "package" does not mean "omitted from the distribution". Instead, we'll construct a distribution by combining the core with a selected set of packages. Initially the selected set of packages will cover everything in the current distribution. Jay and I have been lining up the pieces for this change (it's difficult to make a meaningful proposal without trying a lot of the work, first), and I provide a sketch of the overall plan below. This plan has two prominent implications: * The current git repo's directory structure will change. Anyone who currently works with the Racket repo will need to adapt to the new directory structure (and probably git http://racket-lang.org/download/ will omit sources, including ".rkt" files, ".scrbl" files, and tests. Sources will remain readily available through the git repo and through the package manager, but getting users to try a source-code change will be less convenient than now. See "Binary Builds" below. Repository Reorganization - To convert the current monolith into a core plus packages, we propose to reorganize the Racket git repository by 1. pushing the current content into a "core" subdirectory, and 2. lifting pieces back out of "core" and into new subdirectories, one for each package. The resulting repo will have top-level directories with names like "core", "scribble", "gui", "slideshow", "drracket", and so on. Each directory other than "core" corresponds to a package. We'll have to try this out to discover how finely we can break up the existing tree into packages. At worst, the "mr", "dr", and "plt" layers of "dist-specs.rkt" should work, but I think we'll be able to do better than that. Eventually, when the dust settles, I think we'll want to convert every directory to its own git repo, and then we can incorporate the individual repos as git submodules. Rearranging the repo will obviously break the current build system. Jay and I are creating a new build system, so the current nightly build and distribution processes do not need to adapt (although we're using many existing pieces). The new build system might be ready by the end of the week (and the repo reorganization will wait until the build system is ready). Binary Builds - The proposed switch to binary distributions --- instead of always including source alongside generated bytecode and documentation --- is aimed at reducing dependencies between packages. Support for binary packages is also aimed at supporting faster installs. In terms of dependencies, documentation for a library usually has more dependencies than the library itself. We don't want to limit the *documentation* for package X to avoid using or referring to package Y libraries in order to avoid a run-time dependency of X on Y. For that matter, we don't want to avoid documenting X in order to avoid a dependency on Scribble. A library's tests similarly could have dependencies that are not needed for the library itself. We've adjusted `raco setup' and `raco pkg' to work with collections and packages that are in binary form. "Binary" is not a specific attribute of a package; it's just a package that happens to have ".zo" files without corresponding ".rkt" files, documentation without ".scrbl" sources, and so on. The intent is not for programmers to create binary packages, but to enable an automatic conversion of a source package to a binary package. We can then set up different catalog severs to serve source and binary versions of packages. Finally, we'll be able to quickly create distributions --- either the standard one or others --- by combining a core build with a set of binary packages. Some drawbacks to omitting source are immediately apparent: - Users will be less able to make source changes on their systems to help us debug. Having the binary form of a package installed does not preclude "upgrading" to a source package. So, we could ask a user to use the package manager to install the source form of, say, the "drracket" package, and then try out a change. In that way, users can still help, but it will be less convenient. - Users will be less able to read installed code as examples. Our source code is now easily available via the web interfaces at http://git.racket-lang.org/ and GitHub, so users can always look there, instead. It would be possible, of course, to support distributions and packages that include both source and compiled forms (like our current distribution), but that arrangement requires even more work. We'd like to try out the simpler source vs. binary options, first. More Detail
