Re: New DUB documentation
On Wednesday, 22 November 2023 at 21:52:12 UTC, claptrap wrote: On Wednesday, 22 November 2023 at 21:35:34 UTC, WebFreak001 wrote: [...] IMO you have to many menus, you have menu bar across the top, left side menu, right side menu. So it's like you need to grep all three of them and how the are related to work out where you are. A single table of contents type menu would be better IMO, a left sidebar that gives links to all the pages. It would make it a lot easier to understand where you are in the overall structure of the guide. the layout is standard from material for mkdocs and widely used in other projects, no plans on changing that for now, the experience is more efficient for when you get used to it too.
Re: New DUB documentation
On Wed, Nov 22, 2023 at 09:58:51PM +, Vladimir Marchevsky via Digitalmars-d-announce wrote: > On Wednesday, 22 November 2023 at 21:52:12 UTC, claptrap wrote: > > A single table of contents type menu would be better IMO, a left > > sidebar that gives links to all the pages. > > Wouldn't it be too huge? 5 big separate sections, each has a list of > articles, each article having a number of chapters, sub-chapters, > sub-sub-chapters... Could be optionally expanded depending on where you are in the navigation. T -- Never criticize a man until you've walked a mile in his shoes. Then when you do criticize him, you'll be a mile away and he won't have his shoes.
Re: New DUB documentation
On Wednesday, 22 November 2023 at 21:52:12 UTC, claptrap wrote: A single table of contents type menu would be better IMO, a left sidebar that gives links to all the pages. Wouldn't it be too huge? 5 big separate sections, each has a list of articles, each article having a number of chapters, sub-chapters, sub-sub-chapters...
Re: New DUB documentation
On Wednesday, 22 November 2023 at 21:35:34 UTC, WebFreak001 wrote: the revamped DUB documentation I started a while ago is now deployed on https://dub.pm A bunch of pages are still WIP, but the already done pages have a bunch of new information and should be better structured. I recommend giving the new documentation a try, maybe you will learn something new about DUB. If you find anything to edit, the "Edit this Page" button makes it trivially easy - it's all standard markdown files now that are easily editable. If you previously often looked at the recipe page that contained all the information in a single page, you will find most of the information on https://dub.pm/dub-reference/build_settings/ now and there are even more details on separate pages now. The site's built-in search on the page works great and runs fully offline, try it out! It will find your search across the entire documentation. CLI documentation is now also included more similar to the man page format here. IMO you have to many menus, you have menu bar across the top, left side menu, right side menu. So it's like you need to grep all three of them and how the are related to work out where you are. A single table of contents type menu would be better IMO, a left sidebar that gives links to all the pages. It would make it a lot easier to understand where you are in the overall structure of the guide.
New DUB documentation
the revamped DUB documentation I started a while ago is now deployed on https://dub.pm A bunch of pages are still WIP, but the already done pages have a bunch of new information and should be better structured. I recommend giving the new documentation a try, maybe you will learn something new about DUB. If you find anything to edit, the "Edit this Page" button makes it trivially easy - it's all standard markdown files now that are easily editable. If you previously often looked at the recipe page that contained all the information in a single page, you will find most of the information on https://dub.pm/dub-reference/build_settings/ now and there are even more details on separate pages now. The site's built-in search on the page works great and runs fully offline, try it out! It will find your search across the entire documentation. CLI documentation is now also included more similar to the man page format here.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: In September 2023, we had one planning session. The major item on the agenda was editions. Other items were a new meeting format, the Bugzilla to GitHub migration, and the future of D. ## Attendees The following people attended the session. * Walter Bright * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek ## Editions We had agreed in [the September monthly meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywm...@forum.dlang.org) the week before that we need to define what editions will look like before we start deciding which features should go in any given edition. My goal with this session was to establish the first point on the timeline: a deadline for the editions proposal. I also thought it would be a good opportunity for all of us to clarify what editions are (there were some different ideas about that) and discuss aspects of the concept we need to consider. These are excellent progress. I don't wholly agree with the strong commitment on backwards compability DLF decided to make, but with editions it doesn't matter much. The langauge can remain both backwards compatible and develop further at the same time. Here are some points that came out of the discussion. * Editions are essentially feature sets. Each edition can add/remove/deprecate features. * Editions are entirely opt-in and only affect the source you explicitly apply them to, i.e., they are not transitive to dependencies. Makes sense, but on the other hand we will have a lot of questions about templates that are defined in domain of one language edition and instantiated in another. It's going to be onerous to figure out how those cases will work. Regardless, I'm looking forward to this. * Editions will most likely be implemented via an attribute on the module declaration. We haven't discussed any details about that, but for now, just imagine something like `@edition(2024) module foo;`. The syntax isn't critical anyway. That is one small detail that won't have to dominate the discussions. * Features cannot be opted into individually. When you apply an edition to a module, you get the whole thing. Makes sense again. Lifts a lot of maintenance burden for relatively little user inconvenience. OTOH maybe the existing preview/revert flags should stay for the starting version. * The default edition, meaning the code you have now, should compile forever. * We should have a tool that automates as much as possible the migration of modules to new editions Isn't this what the `-transition` switches do? Regardless, mostly agreed. About the question of what would be the default edition. Like others I tend to think that in cases where neither the module nor the compiler invocation has any definitions it should be the latest stable edition. Why? Adding `-edition=2023` (or whatever the flag for the starting edition would be) to the build script of a legacy project is dead simple, and besides needs to be done only once, after which the project will always compile. People don't hate breakage _that_ much. The reverse situation, that we'd have to always either use `-edition=20xx` or explicilty declare the edition in the module header for new code would have the same problems that our `@system` impure defaults for function attributes. At best, it'd annoy people but more likely it'd more or less lead to new code being written in the starting edition because we don't remember or bother with picking the edition.
Re: DLF September 2023 Planning Update
On Tuesday, 21 November 2023 at 13:13:06 UTC, Guillaume Piolat wrote: I'd argue people come to languages because of arguably alive libraries, and dead libraries less so. Yeah, I think this is solving the wrong problem, but even if we decide to do it anyway it is very important not to hurt alive libs in the name of saving dead libs. If we increase the cost of new and ongoing things, it will lead to more dead things in the future and this would obviously be a bad long term result, even if it looks good in the short term. When alias this breaks the important thing is in my not-so-informed opinion "why DlangUI has few maintenance energy" not "how can we make it still build". Well, part of this too is there needs to be a migration path to achieve the same (or better) job that you can get it. When the cost is small, and ideally if it maintains some compatibility for users with old compilers too, it takes less maintenance energy.
