Re: D pull request review process -- strawman formal definition, query for tools
Steven Schveighoffer wrote: > OK, so now to implement this kind of thing, we need to have a > collaboration tool that allows tracking the review through its workflow. > No idea what the best tool or what a good tool would be. We need > something kind of like an issue tracker (can github issue tracker do > this?). I don't have a lot of experience with doing online project > collaboration except with D. I like trello, but it seems to have not > caught on here. The best tool for this is gerrit: - http://en.wikipedia.org/wiki/Gerrit_%28software%29#Notable_users - Presentation: http://skillsmatter.com/podcast/home/intro-git-gerrit I've downloaded and cut just the gerrit part: http://koch.ro/temp/gerrit_skillsmatter.mp4 - gerrit vs. github pull requests: http://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation Gerrit for D: - Gerrit works on top of Git. - Gerrit is designed to automatically run unit and style checks even before a human reviews the code. - Gerrit tracks the whole history of a change request across all versions of this change. One can see diffs between versions of one particular change request. - Gerrit supports topics to further specify what a change is about Regards, Thomas Koch
Re: Migrating D front end to D - post Dconf
Do you plan to support a build path that has no circular dependendencies? This would be a very strong nice to have for porting D to new architectures. So it should be possible to build a subset of D (stage 1) with gcc without relying on a D compiler and than using the stage 1 binary to build a complete D compiler. There are languages in Debian that rely on themselves to be build and it's a headache to support those languages on all architectures. Regards, Thomas Koch
Re: Migrating dmd to D?
> Walter and I have had a long conversation about the next radical thing > to do to improve D's standing. Like others in this community, we believe > it's a good time to consider bootstrapping the compiler. Having the D > compiler written in D has quite a few advantages, among which taking > advantages of D's features and having a large codebase that would be its > own test harness. Two points from the viewpoint of the Debian distribution: Debian is ported to many different platforms and in average one new platform port started every year. A huge pain point for porters are circular (or self) dependencies. A lot of effort goes into breaking such circles. So in the moment the D language is great in that it does not introduce a new circular dependency. It would be a pity to lose this. The second important thing for Debian (and Fedora and others) is licensing. It's a pity that DMD isn't free software and I believe DMD not being in distros is one reason for the low popularity of D. It's hard to learn D with gdc while all tutorials are based on DMD. So instead of a rewrite of D, it would rather be important (from my humble point of view) to replace non-free parts of DMD. Thank you, Thomas Koch
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
H. S. Teoh wrote: > Huh? Who said anything about master being stable? Obviously master is > unstable by definition, since that's where the development work is being > done. The whole point was to introduce a stable branch where we only > pull in non-breaking changes from master. I think you mean "cherry-pick non-breaking changes from master". Cherry- Picking in Git means to just apply one commit from a given branch to another one instead of merging the complete branch. Thomas Koch
code review and continuous integration (gerrit+jenkins)
Hi, regarding the current discussion of D's stability. Are you all aware of the awesomeness provided by todays toolset for QA? Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit. Gerrit triggers Jenkins to run all unit tests over the new commit. Jenkins reports the result back to Gerrit. If all tests are green and another developer gives his "Looks good to me" (lgtm) then the commit is applied to the target branch. http://vimeo.com/20084957 search google videos for "git gerrit"! I believe that no large software project should be done anymore without a comparable setup. The tools are free software and easy to use. It's just work to do the initial setup. If such a setup exists, everybody should contribute unit tests for the language features he relies on. Gerrit is like githubs pull request for adults with the option to integrate other systems like a continuous integration server (jenkins, buildbot, ...). Sorry if you all knew this before. I'm working on packaging gerrit for Debian. Regards, Thomas Koch
Re: split dmd frontend into separate project
Jacob Carlborg wrote: > On 2012-11-19 15:46, Iain Buclaw wrote: > >> Yes it would make sense - no it can't be done because gdc/ldc makes >> changes to their own copies of dfe. The solution would be to fix dfe >> so that multiple backends can use it. But that it not currently the >> case. > > Wouldn't those changes be easier to make and maintain if the front end > was a separate project, even if it can't be used unmodified. >From an outsiders view I'd believe that it would be much simpler to fork git branches for the dmd frontend versions of gdc and ldc and use the git machinery for merges. - But the developers must decide. I don't want to annoy them. Regards, Thomas
split dmd frontend into separate project
Hi, while browsing the sources of gdc, ldc and dmd I noticed that gdc and ldc both include the verbatim frontend source code from dmd. Wouldn't it make sense to split the free dmd frontend into a standalone project that could then easier be referenced also by gdc and ldc? I'm also asking because I was surprised that debian also contains (a very old version of) ldc[1]. If one day we'd have proper d packages in Debian, it would surely be nice to have only one d frontend package instead of three times the same source code in different packages. [1] http://packages.qa.debian.org/l/ldc.html Regards, Thomas Koch
Re: Binary compatibility on Linux
Russel Winder wrote: > [[I suspect this is getting way off-topic for this list, so if > instructed to take it elsewhere will be happy to do so as long as > elsewhere is defined.]] I added your comments and a remark about the role of make in Debian: http://wiki.debian.org/UpstreamGuide?action=diff&rev1=58&rev2=59 I'd invite you to continue this discussion on debian-de...@lists.debian.org (no subscription required). The UpstreamGuide is an important document for the "public relations" of Debian, so I'd like to get it right. Regards, Thomas Koch
Re: Binary compatibility on Linux
Russel Winder wrote: > On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote: > […] >> > [2] wiki.debian.org/UpstreamGuide >> >> I've read that page and from my understanding they prefer to use "make": >> >> "Please don't use SCons" >> "Using waf as build system is discouraged" > > Comments made by people who are steeped in Autoconf/Automake and haven't > actually used more modern systems such as SCons or Waf. > > The comments on the website are almost, but not quite, totally wrong on > all important points. The "website" is a wiki site edited by many people over a longer time period. If you found points you disagree with I'd love to see a comment added. I for example don't know either SCons or Waf. Maybe the information in our UpstreamGuide is not up to date anymore. Have you found more issues with the text? It would be interesting for us to listen to the opinions of non-debian members. Regards, Thomas Koch
Re: Binary compatibility on Linux
Jacob Carlborg wrote: > On 2012-11-14 19:20, John Colvin wrote: > >> Debian testing is a rolling distribution, so it is always in an unstable >> state. Debian stable is, as it says, stable. To answer your question, >> just look at what debain version the particular ubuntu LTS version is >> based on. > > Good point, how can I do that? Ubuntu versions are not based on Debian _releases_. Ubuntu has an ever repeating development circle of half a year. At the beginning of the circle they take a snapshot of Debian unstable[1] and in the next months they mold this snapshot in an ubuntu release. [1] http://www.debian.org/releases To answer your question: There might be moments, directly after the release of a Debian stable version, when Ubuntu LTS is older then Debian. And after an LTS release the current Debian stable is surely older. >> To be honest, unless you're going to package all your dependancies along >> with the download, then you have to go down one of two routes: source >> distribution with a nice simple build procedure or making packages for >> the main distributions. I would recommend doing both. > > I do provide source distribution. Not much of distribution, it's always > available on Github. But I have one tool, DVM, which is a tool for > installing D compilers and it's also written in D. It's a bit of a > chicken-and-egg-problem. Sure you can get D compiler in other ways. But > I think this tool in particular is very convenient to have available as > a pre-built executable. > > A read a bit about creating packages for Debian, it seemed complicated > and that I need to use stupid tools like Make. I hate Make. You're right about make. However the Makefiles that one needs today for Debian packages are so trivial that it's not worth to worry about it. The most basic debian/rules (which is a Makefile) looks like: #!/usr/bin/make -f %: dh $@ You only need to add additional targets if you want to override default actions. In that case you usually add simple targets with a few lines. We could switch from Makefiles to something else but it's simply not worth the effort. But after all you don't need to do the Debian packaging yourself. It's even a bit infamous if upstream is also the maintainer of the Debian package for different reasons. Just be a good upstream[2] and find a Debian maintainer who cares about your software. The same thing for Fedora. [2] wiki.debian.org/UpstreamGuide Regards, Thomas Koch
Re: [RFC] A huge problem with Github diff
Andrei Alexandrescu wrote: > On 11/14/12 12:36 PM, Andrej Mitrovic wrote: >> On 11/14/12, Alex Rønne Petersen wrote: >>> Or we could switch to Phabricator for our entire review process which >>> has an absolutely awesome side-by-side diff and is generally a fantastic >>> tool for distributed-style software projects. >>> >>> See my email to dmd-internals: >>> http://lists.puremagic.com/pipermail/dmd-internals/2012- October/004900.html >> >> I don't see what's awesome about it > > Everything? :o) Yes, from the featurelist Phabricator looks pretty awesome. And I'm suffering again about an interesting piece of software written in the language of my nightmares: PHP Of course that's only my personal windmill I'm fighting. I just wanted to mention Gerrit Code Review: http://en.wikipedia.org/wiki/Gerrit_%28software%29 I'm in the process of packaging Gerrit for Debian, but this won't be ready before 2013. You can of course install Gerrit with upstreams .war file. Regards, Thomas Koch
Re: D wiki
Andrei Alexandrescu wrote: > The only thing we need to worry about is preserving links lest Google > search pagerank gets lost. Is it possible to keep the old link convention? I don't agree that we have to worry about the pagerank of the existing links. Content about D is not a competitive subject like shopping, porn or news. Once the wiki contains good content about D it should quickly be on the first places on google. A few inlinks from our blogs, forums, twitter, facebook and stackoverflow will suffice. It's astonishing how quickly google lists you on the first page if you have specialized and good content. Regards, Thomas Koch
D wiki
Buna Andrei, I initiated a discussion[1] about the state of the D wiki[2]. [1] http://forum.dlang.org/thread/k6jak1$quh$1...@digitalmars.com [2] http://www.prowiki.org/wiki4d There were three people agreeing that the current wiki engine might be a cause for the bad state of the content. Nobody wants to use this engine. Tobias Pankrath proposed the github wiki engine (free software[3]) and I agreed that it would be best to just enable the wiki in a new project at the D github account[4]. [3] https://github.com/github/gollum [4] https://github.com/D-Programming-Language Now we need a decision on this issue and probably somebody to turn on the github wiki. Multumesc, Thomas Koch
Re: New language name proposal
Flamaros wrote: > How many years it will take to be able to do a search on D that > isn't linked to the code? Like a job search, or anything else? I've done a little bit in the area of search engines. With todays algorithms it's no problem to search for a language with a single letter "D". Modern search engines analyze the context of this "D" and know whether the site is about programming languages or Germany (D for Deutschland). Try searching for "f ide linux"! The computer word "linux" makes it clear to google that f is the name of the programming language. "f ide" is too unspecific. > Why dlang.org and not d.org? Because there is no d.org: http://en.wikipedia.org/wiki/Single-letter_second-level_domain > I think that a name change will affect the speed of the community > grow now, because the effect will be larger at the beginning. Far more important than the name is the network of links between d related content. Only good web sites about d linking to other good websites will make d more visible to search engines and thus to people. I started a discussion about the sorry state of the D wiki[1]. Maybe you'd like to help pushing this issue? [1] http://forum.dlang.org/thread/k6jak1$quh$1...@digitalmars.com Best regards, Thomas Koch
Re: Binary compatibility on Linux
Jacob Carlborg wrote: > On 2012-11-11 10:30, Thomas Koch wrote: > >> The best way is to get your software in the official debian archive. >> There are infrastructure and established workflows to recompile packages >> for each Debian version. >> The backports archive contains newer versions of a package for the >> current stable Debian release. > > I don't want to limit myself to just the debian based package mangers. I > want my tools to be available/usable on all distributions. If your package is in Debian then it is automatically also in Ubuntu, Mint, Xandros, Univention, Aptosid, Knoppix and a few douzend more distributions which are all derivatives of Debian: http://wiki.debian.org/Derivatives/Census http://www.debian.org/misc/children-distros Roughly the other half(?) of the linux universe is based on Fedora, e.g. CentOS, Red Hat: https://fedoraproject.org/wiki/Derived_distributions So by getting your package in the archives of Debian and Fedora, you should serve the large majority of linux users. The Debian wiki has a list of advantages why somebody would want to have his software in a distributions archive: http://wiki.debian.org/AdvantagesForUpstream Best regards, Thomas Koch
Re: Binary compatibility on Linux
Jacob Carlborg wrote: > What's the best way to achieve binary compatibility on Linux? For > example, if I compile an application on, say Ubuntu 12.04, it will most > likely not run on any older versions of Ubuntu but it will run on future > versions. The best way is to get your software in the official debian archive. There are infrastructure and established workflows to recompile packages for each Debian version. The backports archive contains newer versions of a package for the current stable Debian release. Is the software in question free software? It's not that hard to get software in Debian. Have a look at http://wiki.debian.org/UpstreamGuide Regards, Thomas Koch
Mediawiki vs. Gollum vs ...
David Nadlinger wrote: > I still think Mediawiki is the better choice than Gollum if we > want a full-fledged wiki. As far as I can see it, a large part of > the dissatisfaction with the current wiki is precisely that it > doesn't support many of the convenient features people have come > to expect from modern wiki software. But Gollum seems to support > even less features than the prowiki.org software. Hi David, as I said, I don't have a strong opinion here. I'd add "watched pages" as a missing feature in Gollum. On the other hand I've not yet found a solution to clone the content of a Mediawiki instance for offline reading and backup. (I'd much appreciate hints!) The only show stopper of Mediawiki would be, if there was nobody to host and maintain it for D. Can you recommend a Mediawiki hosting service? I'm a contributor to several Mediawiki instances myself and even while I'm hating PHP with a passion I'd still consider it for non-technical topics. > For example, Andrej mentioned above how annoying it was that the > prowiki.org search doesn't work properly. Well, Gollum as running > on github.com doesn't seem to support search at all! I could live without search. If I need it, I use Google with the "site:" parameter to search only the wiki. > Or take user management: MediaWiki supports an extensive set of > tools for setting permission, banning users, protecting pages, > etc., which is proven to work in the real world. On the other > hand, I don't think that Gollum, due to its nature, supports any > kind of access control besides restricting wiki access to, in our > case, d-programming-language.org contributors. This is a problem > because an important part of the wiki concept is that everybody > can edit all/most of the pages, _without_ prior review. For this > to work, you also need to be able to take measures against > vandalism. There are two options: Only contributors can edit or everybody with a github account can edit. Only the latter makes sense for us. Public editing without a github account is not possile (AFAIK). The restriction to github accounts should provide sufficient protection against spam. Best regards, Thomas Koch
Please enable wiki and issues at github
Hi, there has been no objection in this thread[1], that the current D wiki is a burden and should be replaced. The only two proposals were the wiki engine build inside github (gollum[2], free software) and a Mediawiki instance like Haskell. [1] http://forum.dlang.org/thread/k6jak1$quh$1...@digitalmars.com [2] https://github.com/github/gollum I propose to go forward with the gollum proposal and enable the wiki functionality in the d-programming-language.org github project[3]. In addition it might also be a good idea to enable issues in the same project to track website and wiki related issues. [3] https://github.com/D-Programming-Language/d-programming-language.org Github is a proprietary, non-free, cloud service. But it allows you to export all your data. There's the debian package github-backup[5] that one can run by cron to clone all data (wiki, issues) related to a github project. http://packages.qa.debian.org/g/github-backup.html Afterwards I'd kindly ask the current wiki4d[5] maintainer Helmut Leitner to add a static notice to all wiki4d pages pointing to the new wiki. [5] http://www.prowiki.org/wiki4d Do you agree? Regards, Thomas Koch
Re: The D wiki engine must be replaced
Nick Sabalausky wrote: > I don't really understand what's wrong with the current system - unfamiliar syntax like no other wiki engine I've ever seen - no way to have site names without a camelCase - no history other then precedent version - no watched pages - ... surely much more if you try to really use it > What do you mean by "offline editing" though? Go to https://github.com/gtkd-developers/GtkD/wiki/_access You can git clone the whole content of the wiki, read offline, edit offline and push back to the online wiki. Other systems that allow that are for example ikiwiki, gitit and others
Re: The D wiki engine must be replaced
Tobias Pankrath wrote: > What about the wiki engine build into github? The wiki engine is called Gollum[1] and is itself free software. The wiki is editable via the web interface and offline with a text editor. It supports half a douzend popular markups, including markdown, org-mode, restructured text, creole. Of course the wiki could be hosted as a wiki to a separate dummy project under https://github.com/D-Programming-Language. Please don't make it a wiki for the dmd project since D is more then one compiler implementation. Even for me as a free software advocate I'd favour this quick github solution over the current state. It's still possible at any time to setup an own instance of Gollum and host the wiki somewhere else. [1] https://github.com/github/gollum Best regards, Thomas Koch
The D wiki engine must be replaced
Hi, I wanted to edit something in the D wiki[1], had a problem and learned more about the used wiki engine ProWiki. [1] http://www.prowiki.org/wiki4d - The last ProWiki release was in 2006 - This was also the first open source release - Prowiki was apparently developed only by Helmut Leitner - The project is dead by all standards I consider it extremely important for the success of D to have a usable wiki. I don't consider the current wiki usable. I don't have a strong opinion about other wiki engines so I won't give a recommendation here. I personally would prefer a wiki system based on Git to allow offline editing, like Ikiwiki. I don't know the history of the wiki, but it might be adequate to thank Helmut Leitner for his work and efforts. Best regards, Thomas Koch
Invite Distributions to the D-Conf!
Hi, hopefully there'll be D-Conf in 2013. Please try to reach out to Distributions (Debian, Fedora, etc) for a panel to find ways of making D and D libraries and applications available in this Distributions. For Debian the best way for an initial contact would be (I suppose) a mail to pkg-d-de...@lists.alioth.debian.org with an initial CC to debian-de...@lists.debian.org and debian-proj...@lists.debian.org Best regards, Thomas Koch
BNF grammar for D?
Hi, cedet is a collection of emacs dev tools. I understand that it should be relatively easy to enhance the emacs support of D if one just provides cedet with a BNF grammar in a Bison like format, I cite: " You should choose to use the Semantic lexer/grammer format for your language if it has a deterministic grammar. Often times you can download a pre- existing BNF grammar for a language. These BNF grammars can be converted to Wisent grammar format fairly easily. " Is there anything that could be easily translated? Regards, Thomas Koch
Roadmap for Emacs D Mode?
Hi Russel, while we're at it: Is there a roadmap for the D Mode? Will the mode someday be as powerful as a Java IDE? What would we need for that? Would CEDET help? So the feature requests in detail: - completion - jump to declaration - refactoring - error check while writing - run from emacs - run unittests from emacs Some of them might be dreams... Best regards, Thomas Koch
Which build tool to package for Debian?
Hi, which build tool would you recommend to be the first one packaged for Debian? This build tool would then probably also be used to build other D libraries and applications on Debian. There a two outdated/sparse wiki pages on this subject. Please update them rather then responding in this thread: http://www.prowiki.org/wiki4d/wiki.cgi?DevelopmentWithD/Tools/Build http://www.prowiki.org/wiki4d/wiki.cgi?ToolSIG It'd be espacially interesting to see, which tools are still active and which are not worth to have a look at. Thank you very much, Thomas Koch
Re: Emacs D Mode
Russel Winder wrote: > If the former then the maintainers need to set up an efficient release > and distribution mechanism, if the latter then we can assume a > continuous deployment and not worry about releases. Hi, I'd very much like to see the D mode in Debian and we (I'm a maintainer) like to build upstream "releases". But a release does not need to be anything more then just a Git tag with an increasing number. (I also very much like gpg signed Git tags but that's another story...) Best regards, Thomas Koch
Re: The sorry state of the D stack?
denizzzka wrote: > https://github.com/denizzzka/dpq2 Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL Best regards, Thomas Koch
The sorry state of the D stack?
Hi, the subject refers to my current state of sadness after trying to dig into D programming for a few days. I've been very exited after reading "The D programming language", but I've doubts now. - There's no "standard" library to read a single character from the console. Instead people write their own personal helper libraries. - I looked into GtkD, which refers to the build tool DSSS. However DSSS seems to be unmaintained for a couple of years. (Why does every new language needs its own build tool?) - I looked for a PostgreSQL client library. I found small personal hacks and dead projects. - I looked at http://www.dsource.org/forums - most forums are dead. Is it possible that D is a dead language? For a newbie like me it would be very helpful to have a list of good, healthy projects for my first steps in D instead of finding cadavers all around. Typesafe, the company behind Scala, maintains a "Typesafe Stack" of active, recommendable projects. Please don't be offended by this message. I just wanted to provide feedback and will keep trying to get into D. Thank you very much for this wonderful language! Best regards, Thomas Koch
Debian packages for D libraries
Hi, I already asked on D.learn without much response[1]. I'm just starting to learn D (coming from Pascal, PHP, Java) and it feels hard to get started without a single D library packaged in Debian. So I thought we could start getting the libraries from the google code apt repo into official Debian[2]. [1] "Packaging D libraries, cross compiler compatibility" [2] http://code.google.com/p/d-apt/issues/detail?id=1 The open issues seem to be: - Where do header files go? see thread in this group: "I think we need to standardize where D headers are to be installed" - Where do shared libraries go? - Does it matter which compiler produced a shared library? If so, how to deal with it? It would be possible to compile d libraries when the user installs them for every D compiler present on the system. A similar thing is done for emacs lisp files. - Yes, dmd could perfectly be put in Debian non-free. GDC and DMD should both provide the virtual package name "d-compiler". Debians alternatives system can then be used to manage a symbolic link called "d-compiler"(?) to point to either dmd, gdc or anything else. I don't think that some random apt repo on google code is a proper alternative to having D libraries in official Debian. I wouldn't like to add the gpg key of a random site to my apt keyring. I'm a Debian Maintainer, still unexperienced with C/C++/D library stuff but maybe I could help a bit. Best regards, Thomas Koch
