Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
Some thoughts: Hackage includes - making the distinction between program, library. ( plugin ?) - an expanded set of categories Cpan includes - tester reviews - the dreaded 'other' category To improve fundability once you get to thousands of libraries/apps/plugins/frameworks/languages It's not to early to think about an expanded set of categories, or even a more sophisticated vocabulary with a structure like the Library of congress subject headings, though not quite as big. ;) Tagging may also serve this purpose, though it has problems not limited to tags like 'other'. Once you start using more tags/categories how they are used can become a problem. - is a teachpack a plugin, language extension, or a language? The other metadata question that jumps to mind is the licence under which packages are offered. I think this would be important if you integrated collects and planet.(racket app store anyone?) Cheers, Stephen On Tuesday, July 27, 2010, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
Agreed. Done right, I think there's a PhD in this area for a student who likes to build and measure systems, including social networking measurements. Robby and I had a grant that kind of was a seed for this direction: equip planet libraries with contracts and see how it pressures others to write down contracts at the boundary. Too much work, too little time killed this project in a way though Robby did add a good amount of infrastructure to Planet. On Jul 27, 2010, at 11:59 PM, Jay McCarthy wrote: I think we can and must improve the browsing, searching, rating, etc parts of PLaneT. There's no shame in copying Hackage, CPAN, etc on these areas because they are probably very wise in their decisions. I would like to make DrDr build and test every PLaneT package on some basis (perhaps when the version number changes), but I'll have to make DrDr capable of running untrusted code to do that and there's the can of worms related to system dependencies. Jay On Tue, Jul 27, 2010 at 3:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Jul 28, 2010, at 12:26 AM, YC wrote: Other package systems separate the installation step from the import step Indeed, this is the key design decision separating us from the rest of the world, and it is not clear whether it was a good decision. On Jul 27, 2010, at 11:57 PM, Jay McCarthy wrote: something I see as a design principle behind Racket) because we instead write (require (planet nintendo/ds)) This is indeed a principle that was explicitly stated during our time at Rice, over and over again. If it's worth saying, it's worth saying in the language. Thinking about the location of this additional information points to me that we currently have only internal linking of packages. This could also be a solution to the point YC makes. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
YC wrote: Robby Findler wrote: I guess the idea is that you'd eliminate the syntactic difference between a planet-located library and one in the distribution and then require on some external source to know where the package is located? Something like that? How would that work? Hi Robby - there are a lot of ways to go about doing this; Jay pointed to some ideas. Here's one KISS approach without major changes (assuming the syntax have been unified): Modify the module path resolver so that it does the following lookup for non-versioned require specs: try lookup the package in COLLECTS if #1 fails, lookup the package in planet cache if #2 fails, lookup the package in planet repo For the versioned specs, you can skip the collects step above since it is currently not versioned. But of course you can also change collects to become versionable in the future if you wish to re-architect the system. I agree with pretty much everything said so far. Here are some further thoughts: I've expressed a desire in the past to be able to specify versioned dependencies on some of the big libraries that are in core. I could, say, get that new bug fix in SRFI 19 without having to worry about upgrades to other core libraries. I'd also like to be able to set up a PLaneT proxy to add in-house libraries in on the top of publicly available libraries from planet.racket-lang.com. This would let me get rid of a bunch of nasty hacks and scripts in the current Untyped build process. Racket's main distribution is big and takes time to compile and install. I'd personally be in favour of a leaner core distribution with more code in external packages, so I can choose what I download when I'm only interested in a single web application. Of course, it would also useful to have a kitchen sink distribution that gives you everything you need if you don't have a network connection on your PC. Cheers, -- Dave _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Jul 28, 2010, at 10:03 AM, Dave Gurnell wrote: Racket's main distribution is big and takes time to compile and install. I'd personally be in favour of a leaner core distribution with more code in external packages, so I can choose what I download when I'm only interested in a single web application. Of course, it would also useful to have a kitchen sink distribution that gives you everything you need if you don't have a network connection on your PC. That was an extremely timely remark, and I suspect that Eli will now offer to buy you two Scotch next time we get together in Edinburgh. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
To add to what Dave said, quick brain dump, hopefully not too unreadable... Most important for me, I'd like to be able to define multiple (what I'll call for now) repositories (like Debian apt). So that I can have, for example, a repository for core official blessed Racket components, one for contributed (what's currently PLaneT), and one for packages internal to an organization or project. (Note that Debian has a mess of features for managing using multiple repositories, which most people don't know about, and which aren't necessarily reliable because not all tools respect the policy and some of the policy is kludgey anyway.) Then, somehow I would like to prevent packages in the contributed repository from overriding those in the core and internal repositories. Guaranteeing this through naming, like Java packages, is one way, though that could be cumbersome. It would be nice to be able to set policy in one place, for what packages and versions may be pulled from the non-internal repositories for a particular large system. For example, since there are cost/benefit tradeoffs, to each third-party package we use, including security and quality, a project team might want to declare this project may only use package foo version 1.3 and package bar versions 2.1-2.3 from the contributed repository, and no others at this time. (I have started to partly approximate this in one large system by having an intermediary planet-*.ss for each permitted require from PLaneT, but that alone does not prevent programmers from adding requires directly from PLaneT.) Package signing to authenticate the packager still seems useful, like it did in the beginning, but that could be revisited in context of whatever other improvements are made. When pulling from the contrib repository, we sometimes also need some confidence that version 1.3 today is the same code as when we vetted version 1.3 six months ago. Maybe that's satisfied by us pulling from a transparent copy we made at the time (and not accidentally pulling from the repository). Or maybe we copy the code and permanently disentangle it from PLaneT, which is expensive and stodgy. Or maybe we trust the PLaneT server and our link to it not to be compromised, which we can for some applications but certainly not for all. Or something else. Separately, breaking up the monolithic Racket distribution into PLaneT-ish packages has some appeal to me, though it is not as important to me as the things above. This appeal is partly pragmatic, such as an assumption that the factoring into modules will have a side effect of fitting Racket onto smaller storage, and the (rare, in my case) desire to pull some released improvement into a production system that is mostly frozen at an earlier Racket version. The other part of appeal, at least to me, is aesthetic, in the same way that a self-hosting language implementation is considered elegant, and we might expect practical benefits to someday fall out of that (or perhaps they don't). If numerous PLaneT requests were actually used for the normal way of installing core, however, either all-at-once or on-demand, that could result in a poorer install-time or run-time experience than currently. So I think a monolithic tarball/zip/etc/dmg/etc would still be a good idea, even if internally it's broken up into packages. If breaking up core into packages, and still offering a monolithic distribution tarball, whatever policy affordances the implementation of that monolithic packaging adds to PLaneT caches might also be applicable to purposes mentioned above, like selectively using a few contrib packages and being confident they don't change. I'm guessing that most of this is relevant only to people doing large development, and who are engineering-inclined and looking to safe effort and stress. However, one does not necessarily need these things to do large development successfully in Racket and using contributed PLaneT packages. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Wed, Jul 28, 2010 at 1:09 AM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: It's not to early to think about an expanded set of categories One idea is to allow module writers to add to the categories or tags so it becomes a decentralized process, like how blogs do it these days. On Wed, Jul 28, 2010 at 6:41 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jul 28, 2010, at 12:26 AM, YC wrote: Other package systems separate the installation step from the import step Indeed, this is the key design decision separating us from the rest of the world, and it is not clear whether it was a good decision. I personally like the design except for the issues I've raised so far, but the disadvantage can be remedied by unifying the require spec syntax between collects and planet. On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell d.j.gurn...@gmail.com wrote: I'd also like to be able to set up a PLaneT proxy to add in-house libraries in on the top of publicly available libraries from planet.racket-lang.com . See my bzlib/planet package. This is an example where I would like to see the core team take advantage of what's available on planet directly instead of porting it into core. On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: Most important for me, I'd like to be able to define multiple (what I'll call for now) repositories (like Debian apt). FWIW - bzlib/planet is designed for you to facilitate having your own internal packages now. When multi-repo becomes available, you can still use bzlib/planet to host your own repo. On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell d.j.gurn...@gmail.com wrote: I'd personally be in favour of a leaner core distribution with more code in external packages, so I can choose what I download when I'm only interested in a single web application. Once the collects and planet require syntax are unified - moving the currently-core packages to planet will become a snap. At that time it might even be possible to have build your own distribution by picking your own packages. On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: Then, somehow I would like to prevent packages in the contributed repository from overriding those in the core and internal repositories. Guaranteeing this through naming, like Java packages, is one way, though that could be cumbersome. Now I think about it, it might make sense to have local repo able to overwrite core repo in case you want to patch the core code. In that case the module resolve I proposed earlier would have to be changed to: 1. Try lookup the package in planet cache 2. If #1 fails, lookup in COLLECTS 3. If #2 fails, try lookup the package in planet repo On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: Package signing to authenticate the packager still seems useful, like it did in the beginning, but that could be revisited in context of whatever other improvements are made. I like what ASDF has to offer here. The only thing I would add is that this auth mechanism should be optional (perhaps as a policy per repo). All my additional 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] haskell's 'hell of a lot of libraries', planet
If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
IMHO planet works very well and shouldn't have issue to scale beyond a few thousand packages if it ever gets to that point. However, to get there I believe planet first needs one major upgrade - it needs to become location transparent - meaning that requiring modules in COLLECTS and PLANET look exactly the same from code perspective. With this change the invisible cultural divide between planet and core distribution will disappear, and core team can tap into the work of module developers, which in turn will help module developers feel more involved in the community - the virtuous cycle can then be built to gain momentum to increase the community. I have discussed the issues in detail back in January in the thread http://lists.racket-lang.org/users/archive/2010-January/037703.html - and love to discuss further if others are interested. Cheers, yc On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
I recall your proposal from back then, and I will give you my thoughts: 1. a 'remote url' require (which is what Planet boils down to) imposes a serious cost overhead (for compilation) and a connectivity overhead (suppose I send you code and you wish to compile it on your netbook while on the subway). People who get this kind of code should be aware of it. At a minimum, the path should start with /planet/ and that'll set it apart. (There's more, such as versioning.) 2. it is easy to find and fix collects code. Planet's download mechanism would have to change a lot to enable that. On Jul 27, 2010, at 9:17 PM, YC wrote: IMHO planet works very well and shouldn't have issue to scale beyond a few thousand packages if it ever gets to that point. However, to get there I believe planet first needs one major upgrade - it needs to become location transparent - meaning that requiring modules in COLLECTS and PLANET look exactly the same from code perspective. With this change the invisible cultural divide between planet and core distribution will disappear, and core team can tap into the work of module developers, which in turn will help module developers feel more involved in the community - the virtuous cycle can then be built to gain momentum to increase the community. I have discussed the issues in detail back in January in the thread http://lists.racket-lang.org/users/archive/2010-January/037703.html - and love to discuss further if others are interested. Cheers, yc On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
I looked at the message where you link and I didn't see how one would go about this. I guess the idea is that you'd eliminate the syntactic difference between a planet-located library and one in the distribution and then require on some external source to know where the package is located? Something like that? How would that work? Robby On Tue, Jul 27, 2010 at 8:17 PM, YC yinso.c...@gmail.com wrote: IMHO planet works very well and shouldn't have issue to scale beyond a few thousand packages if it ever gets to that point. However, to get there I believe planet first needs one major upgrade - it needs to become location transparent - meaning that requiring modules in COLLECTS and PLANET look exactly the same from code perspective. With this change the invisible cultural divide between planet and core distribution will disappear, and core team can tap into the work of module developers, which in turn will help module developers feel more involved in the community - the virtuous cycle can then be built to gain momentum to increase the community. I have discussed the issues in detail back in January in the thread http://lists.racket-lang.org/users/archive/2010-January/037703.html - and love to discuss further if others are interested. Cheers, yc On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
Basically, CPAN is a way of distributing and finding tarballs that have Perl code it in. The CPAN tool installs these things into a system or user directory of collects. People have written Perl modules that overload the module lookup to find and download new CPAN packages if necessary. If PLaneT worked the same way, it would just be a way of distributing our .plt files. We'd have a more powerful planet tool to deal with these. Instead, we make the syntactic difference YC mentions. -- If PLaneT didn't work this way, then when I have a file that reads (require ds), it isn't meaningful without additional information about what packages ( versions thereof) should be installed before compiling and running it. One argument in favour of how PLaneT currently works is that this additional information is in the language (something I see as a design principle behind Racket) because we instead write (require (planet nintendo/ds)). Thinking about the location of this additional information points to me that we currently have only internal linking of packages. I can imagine an external linkage where, for example, the nearest info.rkt file specified what packages needed to be installed. [Perl modules have something similar to that actually.] Jay On Tue, Jul 27, 2010 at 8:06 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I looked at the message where you link and I didn't see how one would go about this. I guess the idea is that you'd eliminate the syntactic difference between a planet-located library and one in the distribution and then require on some external source to know where the package is located? Something like that? How would that work? Robby On Tue, Jul 27, 2010 at 8:17 PM, YC yinso.c...@gmail.com wrote: IMHO planet works very well and shouldn't have issue to scale beyond a few thousand packages if it ever gets to that point. However, to get there I believe planet first needs one major upgrade - it needs to become location transparent - meaning that requiring modules in COLLECTS and PLANET look exactly the same from code perspective. With this change the invisible cultural divide between planet and core distribution will disappear, and core team can tap into the work of module developers, which in turn will help module developers feel more involved in the community - the virtuous cycle can then be built to gain momentum to increase the community. I have discussed the issues in detail back in January in the thread http://lists.racket-lang.org/users/archive/2010-January/037703.html - and love to discuss further if others are interested. Cheers, yc On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
I think we can and must improve the browsing, searching, rating, etc parts of PLaneT. There's no shame in copying Hackage, CPAN, etc on these areas because they are probably very wise in their decisions. I would like to make DrDr build and test every PLaneT package on some basis (perhaps when the version number changes), but I'll have to make DrDr capable of running untrusted code to do that and there's the can of worms related to system dependencies. Jay On Tue, Jul 27, 2010 at 3:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
Thanks Matthias - please see inline. On Tue, Jul 27, 2010 at 7:03 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: 1. a 'remote url' require (which is what Planet boils down to) imposes a serious cost overhead (for compilation) and a connectivity overhead (suppose I send you code and you wish to compile it on your netbook while on the subway). People who get this kind of code should be aware of it. At a minimum, the path should start with /planet/ and that'll set it apart. (There's more, such as versioning.) Location non-transparency matters a lot in remote API calls since each calls incurs non-trivial network overhead. However, the 'remote url' require is only remote the *very first time*; once compiled it exists in cache and hence incur no additional overhead. Whereas the planet prefix incur the awareness overhead every single time. I.e., the cost is greater than the benefit. Other package systems separate the installation step from the import step, and in such systems the subsequent use of the package appears exactly the same as a local package. If we want `require` to continue to handle both first-time install and subsequent import, and we wish to unify the syntax, then what we can do is to make the first time interactive - i.e. when we require a package that has not been cached, we can prompt the user saying this package resides on planet - do you wish to download and continue the installation?. There are probably better UI approaches, but that's an idea. For versioning - any explicit version can be cached in planet style, and all version exists on planet systems. What this means is once planet and collects unify, you can have the different versions of collects packages living in planet. 2. it is easy to find and fix collects code. Planet's download mechanism would have to change a lot to enable that. This is the cultural issue that I am talking about. To use other people's code there needs to be trust that other people's code will be supported. The trust won't be built over night, but you also will not start using other people's code en masse. So there is time to build that trust. At first, most likely you will only try out a few packages, and probably from people that are already contributing to the collects packages, since you know them. But then eventually you will be able to include more people once the approach is understood and tested. Currently - the above is not possible at all since the platform prohibits it. So the platform needs to be fixed first before the culture will change. If direct source tree access is desired, then perhaps providing a planet source control system for module writers to opt-in for packages that become candidates to be included in the core system can be a requirement. This probably looks like a lot of chores at first, but the community can grow this way by giving module writers a chance to participate. My 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Tue, Jul 27, 2010 at 7:06 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I guess the idea is that you'd eliminate the syntactic difference between a planet-located library and one in the distribution and then require on some external source to know where the package is located? Something like that? How would that work? Hi Robby - there are a lot of ways to go about doing this; Jay pointed to some ideas. Here's one KISS approach without major changes (assuming the syntax have been unified): Modify the module path resolver so that it does the following lookup for non-versioned require specs: 1. try lookup the package in COLLECTS 2. if #1 fails, lookup the package in planet cache 3. if #2 fails, lookup the package in planet repo For the versioned specs, you can skip the collects step above since it is currently not versioned. But of course you can also change collects to become versionable in the future if you wish to re-architect the system. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Tue, Jul 27, 2010 at 8:57 PM, Jay McCarthy jay.mccar...@gmail.comwrote: If PLaneT worked the same way, it would just be a way of distributing our .plt files. This is a great way to think about planet - a distribution mechanism that can be used to distribute any package. On Tue, Jul 27, 2010 at 8:59 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I think we can and must improve the browsing, searching, rating, etc parts of PLaneT. There's no shame in copying Hackage, CPAN, etc on these areas because they are probably very wise in their decisions. +1. AFAICT CPAN is still the gold standard today that can be emulated. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
