Re: dsource.org moved
I haven't been active on the newsgroups lately, so lose track of what's going on. Has anything happened? Just now I tried to commit to the bindings project on dsource, but got an error "POST request on '/projects/bindings/!svn/me' failed: 500 Internal Server Error" Has it been doing this for a long time? Or is it just a temporary problem? Bindings is certainly a project that needs to be kept alive, whether here or somewhere else, but either way it needs to be possible to commit to it. There's already a mirror of bindings on GitHub. https://github.com/CS-svnmirror/dsource-bindings I don't know if it would be reasonable to convert this into the live bindings repository. The name 'CS-svnmirror/dsource-bindings' implies that it's a mirror of the dsource repo - can the name be changed? Or would we need to create a new repo on GitHub to carry on where the dsource one left off? Moreover, I haven't taken the time to get to know GitHub. I've just realised that at least it has a wiki facility. Is it structured in basically the same way as the dsource wiki? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 07/04/2015 19:34, Vladimir Panteleev wrote: On Tuesday, 7 April 2015 at 16:33:37 UTC, Stewart Gordon wrote: I haven't been active on the newsgroups lately, so lose track of what's going on. Has anything happened? Just now I tried to commit to the bindings project on dsource, but got an error "POST request on '/projects/bindings/!svn/me' failed: 500 Internal Server Error" Has it been doing this for a long time? Or is it just a temporary problem? Bindings is certainly a project that needs to be kept alive, whether here or somewhere else, but either way it needs to be possible to commit to it. Sorry about that. It looks like pushing to SVN is broken. I don't remember if this is a new problem. I've just spent two hours trying to fix it, and though I thought I made some progress, now some Apache module is mysteriously segfaulting. I'm not sure if I should spend more time on this. I've just tried committing again. And it seems it's generally managing to send one or two files and then failing on the next. (Though admittedly, I didn't think I had *that* many pending updates! They seem to be mostly small tweaks.) Command: Commit Modified: C:\Users\Stewart\Documents\Programming\D\win32\aclui.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\basetyps.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\commctrl.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\commdlg.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\dbt.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\dhcpcsdk.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\directx\dsound8.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\imm.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\mswsock.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\ntsecapi.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\ras.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\rpcdce.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\w32api.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\winbase.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\windef.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\winnt.d Modified: C:\Users\Stewart\Documents\Programming\D\win32\winuser.d Sending content: C:\Users\Stewart\Documents\Programming\D\win32\ntsecapi.d Sending content: C:\Users\Stewart\Documents\Programming\D\win32\dbt.d Sending content: C:\Users\Stewart\Documents\Programming\D\win32\windef.d Error: Commit failed (details follow): Error: PUT request on '/projects/bindings/!svn/txr/433-6/trunk/win32/windef.d' failed: Error: 500 Internal Server Error Error: Additional errors: Error: DELETE request on '/projects/bindings/!svn/txn/433-6' failed: 500 Internal Error: Server Error Completed!: And since the design of SVN is such that commits are atomic, this causes the whole commit to fail. So I guess I'll have to try committing just a few at a time and see if that works. Still, if you can get it working more reliably it would be most helpful. Yes, we can move the repository to GitHub. Since Git is distributed, you could just clone the mirror, create a new repository, and push it there. I'll remove my mirror then, to avoid confusion. We would need to make sure people know that the bindings project is finally being moved across. I suppose that we would migrate the wiki pages across at the same time as we do this, and replace them on dsource with a notice telling people where to find it. Speaking in broader terms, I think the only useful part of the bindings project is the Win32 API. Everything else is provided from Derelict or Deimos. Ultimately, I think the bindings should be moved to Druntime, but it would take some work to integrate them with the existing ones to allow a seamless transition. Yes, a set of bindings to eventually put into Phobos/druntime was the aim of the WindowsAPI project from the beginning. But unfortunately, progress has been slow. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 07/04/2015 22:44, Stewart Gordon wrote: So I guess I'll have to try committing just a few at a time and see if that works. Oh dear, it seems even that doesn't. It isn't predictable at what point it will fail, but every single time it's failing somewhere. Even if I try to commit just one file at a time. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 08/04/2015 03:21, Rikki Cattermole wrote: On 8/04/2015 9:44 a.m., Stewart Gordon wrote: snip Yes, a set of bindings to eventually put into Phobos/druntime was the aim of the WindowsAPI project from the beginning. But unfortunately, progress has been slow. Instead of moving to Github, this should be done instead. Thanks to package.d files it shouldn't be too hard to up and replace into core.sys.windows.windows. How would we go about committing updates to it when this is done? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 16/04/2015 03:35, Rikki Cattermole wrote: On 16/04/2015 11:25 a.m., Stewart Gordon wrote: How would we go about committing updates to it when this is done? Let's say there is a new function in gdi.h added. You would look for the file: core/sys/windows/windows/gdi.d And add the function declaration. Or if it is a whole new file: Add: core/sys/windows/windows/newFile.d Add line: public import core.sys.windows.windows.newFile; To: core/sys/windows/windows/package.d Basically the same process as now, except spread out across more files. I don't understand - how would an average member of the D community get into the DMD package on dlang.org in order to apply these updates? -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 17/04/2015 02:19, lobo wrote: On Thursday, 16 April 2015 at 23:32:17 UTC, Stewart Gordon wrote: I don't understand - how would an average member of the D community get into the DMD package on dlang.org in order to apply these updates? Get DMD, Druntime and Phobos and build them: http://wiki.dlang.org/Building_DMD Why would one need to build DMD in order to make changes to a set of API bindings? Make your changes and test. Contribute your changes back to D using pull requests. http://wiki.dlang.org/Pull_Requests Has Walter promised us that every pull request for the WindowsAPI bindings will be put in right away? Even if he had, what would be the point? It would greatly slow down the whole process. We have SVN repositories so that people can just put their updates straight in, and everyone else not only has access to the update straight away but can obtain it with either a one-line command line invocation or a few mouse clicks. The only problem is that the SVN server that is currently hosting the bindings doesn't work properly. We already have a potential solution: moving it across to Github. As such, I'm going to see if I can figure out how to do this. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
The wiki is terribly broken at the moment. I just edited a page http://www.dsource.org/projects/bindings/wiki/WikiStart and it changed every linebreak to the literal string `\r\n`. The page looks OK in preview, but then it breaks when you actually save it. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Trial migration of Dsource bindings project to Github
In the light of problems with SVN on dsource, the Bindings project has been migrated to GitHub on a trial basis. Apparently this is more or less the last "active" project on Dsource, so after a brief discussion on another thread I have decided to give it a try. So it's now at: https://github.com/smjgordon/bindings Please don't confuse this with dsource-bindings, which is an automatically updated mirror of the Dsource project. The one I have linked to is a new repository on GitHub which may become the live repository for the Bindings project. For those of you who are still unfamiliar with GitHub, it's a Subversion repository just like we had on dsource, so you don't need to learn a new way of working or obtain any new tools - you just need to set up a GitHub account if you don't have one already. Could people please try checking out the project on GitHub, and committing a change? There's still plenty of work to do on WindowsAPI so you could do some of the work there. (The wiki is broken at the moment, so I don't recommend trying to edit the module list there, but as a temporary measure you could just post on this thread if you're going to do some major work on one or more of the files.) Failing that, there's a file test.txt (directly under trunk) which you could make a dummy edit to. But whatever you do, please be sure to reply to this thread to let me know whether or not you could commit successfully. If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will be migrated in due course. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: Trial migration of Dsource bindings project to Github
On 20/04/2015 00:37, Vladimir Panteleev wrote: On Sunday, 19 April 2015 at 23:14:13 UTC, Stewart Gordon wrote: For those of you who are still unfamiliar with GitHub, Stewart, I haven't seen an active D project that WASN'T hosted on GitHub for years now. That doesn't mean absolutely none of us are just doing personal projects which we keep on our own computers. Could people please try checking out the project on GitHub, and committing a change? Git commits are local, and will always succeed. I committed some updates the other day and they seem they have gone straight into the online repository. I'm guessing you actually want to allow anyone to push their commits to your repository, which is not how collaboration on GitHub works. You may want to read up on pull requests: https://help.github.com/articles/using-pull-requests/ That mentions a 'shared repository model'. What is that if not a way of enabling any user to push changes? (That said, it isn't clear at the moment how to control whether a given repository is fork-pull or shared, or even whether the distinction is at the repository setup level or some other.) It's too late in the day for me to take much in at the moment, but another page I've found http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access seems to say that, if I make somebody a 'collaborator', then that somebody will be able to commit to my repository. The module list has no value these days. Most people in that list no longer use D. ?? The module list is a list of modules, not a list of people. Git allows quickly checking the history of any one file. Contributions to the project itself have been so few that it makes no sense to partition out module ownership. That isn't the sole purpose of the module list. It also serves to document the status of each file. If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will be migrated in due course. Given that SVN is going the way of RCS and CVS, it's not really an "if". What do you mean by this? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 20/04/2015 00:25, Vladimir Panteleev wrote: Even if he had, what would be the point? It would greatly slow down the whole process. We have SVN repositories so that people can just put their updates straight in, Only those who have access can do that. Getting patches into the bindings repository has been historically difficult. Committers have had to commit patches on behalf of other people. ?? When I worked on the project on dsource, until it stopped working recently I generally had no trouble just committing my updates using SVN. I didn't have to create patches at all. As I understood it, neither did anybody else who helped out (after all, it wasn't _my_ dsource project). Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 21/04/2015 00:19, Stewart Gordon wrote: ?? When I worked on the project on dsource, until it stopped working recently I generally had no trouble just committing my updates using SVN. I didn't have to create patches at all. As I understood it, neither did anybody else who helped out (after all, it wasn't _my_ dsource project). OK, so come to think about it, maybe those who were collaborating were given commit access on dsource as and when. And maybe one or two projects were completely open read/write access. My memory of how access control worked is blurred. In the other thread I referred to this http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access which makes it sound as though it's possible to do the same thing in GitHub. Is that page wrong? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: Trial migration of Dsource bindings project to Github
On 21/04/2015 00:42, Vladimir Panteleev wrote: Committing is a local (non-network) operation in git, so you must have pushed them afterwards, or your GUI has done this for you. I committed using TortoiseSVN. Would that auto-push? I never imagined so. The shared repository model rarely applies to open-source projects, and I don't think it applies to the bindings project. Empty comments like "I don't think" don't help any of us. We need to try and figure out whether it applies, and if not then how to make it apply. SVN use, especially in open-source projects, has heavily declined in the past years. People have begun maintaining their own forks and mirrors of the bindings project Who are these people? just so they wouldn't have to muck with SVN. How is mucking with SVN a burden? It takes only either a one-line command line invocation or a few mouse clicks to update or commit. It seems to me that if people are maintaining their own forks then it's more likely to be because they want the additions they make all to themselves for their personal projects, rather than to contribute to the project. The bindings project needs to move away from SVN if it is to avoid fragmentation and be friendly to contributions. How does using SVN lead to "fragmentation"? I don't understand. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 21/04/2015 00:35, Vladimir Panteleev wrote: In the other thread I referred to this http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access which makes it sound as though it's possible to do the same thing in GitHub. Is that page wrong? This question pertains to private GitHub repositories (a feature of paid plans). One of the comments there: "Or you make your repository public, then everyone (who is not a collaborator) has read-only access" And everyone who _is_ a collaborator has what? Regardless, I do not recommend attempting to shoehorn your previous SVN workflow into git and GitHub. The usual way contributions are done with GitHub is that anyone with a GitHub account can create a pull request (a series of commits, initially published on their own fork of the repository), which the repository owner (or collaborators) can then accept (merge) into the main repository. https://en.wikipedia.org/wiki/Fork_%28software_development%29 implies that a fork is a divergent development branch - a separate copy of the project that has no ongoing link to the original. Is the Git concept of a fork different? Instead of designating a group of committers as in SVN, you would simply need to review pull requests and click the "merge" button to accept them. If you do not foresee yourself being available often enough to review/accept pull requests, you can designate a few collaborators who can do it as well. Maybe I'll do that. Most of the time I should be available enough, but there's always the chance that I'll be away for a week every now and again (possibly longer if I'm lucky). Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: Trial migration of Dsource bindings project to Github
On 24/04/2015 11:58, Kagamin wrote: On Tuesday, 21 April 2015 at 21:31:39 UTC, Stewart Gordon wrote: How does using SVN lead to "fragmentation"? I don't understand. See http://forum.dlang.org/post/mailman.3160.1418550079.9932.digitalmar...@puremagic.com ?? I've had a quick look, and can't at the moment see what in that thread relates to using SVN. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 22/04/2015 08:20, Jacob Carlborg wrote: If you're forking a project on Github you get your own copy of the project. The projects are linked but the repositories are not. What I mean by that is on your fork you'll see that it is a fork with a link back to the original project. From the original project you can also view all forks. The repositories are not linked in the sense that there's no automatic syncing of code between them. The fork needs to manually pull from the original repository to get the latest changes. I guess the word "link" has too many meanings. :p So a fork is really a working copy of the master repository, and the code that the user will typically edit is in turn a working copy of this. And "commit" and "push" in Git terms basically mean to commit to the local fork and to commit the fork to the master repo respectively. So if "pull" means to update one's fork, what is a "pull request" requesting exactly? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: Summer cleanup on https://issues.dlang.org
On 09/06/2015 06:33, Andrei Alexandrescu wrote: * Consolidated D1 & D2 issues under D2. It appears that you've changed everything to D2 indiscriminately, including issues that have nothing to do with the D language or compiler, let alone D2 (e.g. issues with the Bugzilla installation, and issues with Dstress, which IIRC was never updated to D2). If we effectively aren't using the Version field anymore, we ought to do away with it. I'm guessing there's a way to remove this field from the interface, but I don't know. If we're keeping it, we really should have either some kind of 'N/A' option for issues that aren't about the D language or compiler, or versions in the list for these other tools as well. * Retired D1. It's closed for new submissions. What has happened to those bugs that were applicable to D1 only - either specific to D1 in the first place or fixed in D2 but not in D1? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.