Re: Trial migration of Dsource bindings project to Github
On 2015-04-21 01: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. Just for the record, it is possible to use SVN to interact with repositories on Github [1], including committing. https://help.github.com/articles/support-for-subversion-clients/ -- /Jacob Carlborg
Re: This week in D #14: job opening, Silicon Valley meetup, Dsource on GitHub
On Monday, 20 April 2015 at 06:39:00 UTC, weaselcat wrote: On Monday, 20 April 2015 at 06:23:36 UTC, ketmar wrote: as Adam didn't post announce for current TWiD, i'll try to do that instead, as i like to see that announcements here. http://arsdnet.net/this-week-in-d/apr-19.html the notable thing is "Job Opening" part. let's hope that it will become regular. not with the same content each week, of course. no tip/trick :( Here's a useless trick: Peano numbers and type-level lists. http://dpaste.dzfl.pl/9f92af9d97f4
Re: Trial migration of Dsource bindings project to Github
On Monday, 20 April 2015 at 22:57:51 UTC, Stewart Gordon wrote: I committed some updates the other day and they seem they have gone straight into the online repository. Committing is a local (non-network) operation in git, so you must have pushed them afterwards, or your GUI has done this for you. 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.) The shared repository model rarely applies to open-source projects, and I don't think it applies to the bindings project. 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. Sorry, I was talking about the "Assigned to" column. I was misremembering, I agree it might be worth migrating to the GitHub wiki. Given that SVN is going the way of RCS and CVS, it's not really an "if". What do you mean by this? 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 just so they wouldn't have to muck with SVN. The bindings project needs to move away from SVN if it is to avoid fragmentation and be friendly to contributions.
Re: dsource.org moved
On Monday, 20 April 2015 at 23:27:58 UTC, Stewart Gordon wrote: 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. I believe this is the case. That, or they simply didn't have SVN installed. They sent a PR to my GitHub mirror instead. 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). 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. 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.
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: 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: 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: [hackathon] One week left to the first D Hackathon!
On Monday, 20 April 2015 at 12:17:13 UTC, Andrei Alexandrescu wrote: On 4/19/15 9:03 AM, ANtlord wrote: Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? Yes! The hackathon is exclusively online and distributed! And second question. Will hackaton's projects be published? It's the choice of each author! My hope is that out of this we'll have some good bugfixes, good stuff in http://code.dlang.org, and maybe a good couple of articles. Andrei This would be a great outcome. Some more links/ideas for starter projects might be nice for those interested in getting involved but not knowing the best places to begin.
Re: dfmt 0.3.0
On Monday, 20 April 2015 at 20:59:43 UTC, Idan Arye wrote: Looks nice. BTW, it looks like the editorconfig format has something called "Domain-Specific Properties" I didn't use those because they're not standardized. Anything prefixed with dfmt_ is a domain-specific property. I'm also avoiding those because it doesn't say what to do when you specify "curly_bracket_next_line = true" and "indent_brace_style = K&R" at the same time.
Re: dfmt 0.3.0
On Monday, 20 April 2015 at 17:40:48 UTC, Brian Schott wrote: https://github.com/Hackerpilot/dfmt https://github.com/Hackerpilot/dfmt/releases/tag/v0.3.0 dfmt is a D source code formatter. Version 0.3.0 fixes several bugs and introduces the ability to place configuration options in your projects' .editorconfig files. Random stats: 9000 possible bike shed colours 2555 lines (according to wc) 1477 lines of code (according to D-Scanner) 98 regression tests 11 issues closed in this release 2 ways to spell "color" Looks nice. BTW, it looks like the editorconfig format has something called "Domain-Specific Properties"(https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#ideas-for-domain-specific-properties) - configurations that only make sense for a limited number of languages or file formats. Some of dfmt-specific properties can fit there - for example dfmt_brace_style can be indent_brace_style. The other dfmt-specific properties can not be mapped to that list, but most of them are not really D-specific, so you can make PRs for properties you want to reserve the name.
dfmt 0.3.0
https://github.com/Hackerpilot/dfmt https://github.com/Hackerpilot/dfmt/releases/tag/v0.3.0 dfmt is a D source code formatter. Version 0.3.0 fixes several bugs and introduces the ability to place configuration options in your projects' .editorconfig files. Random stats: 9000 possible bike shed colours 2555 lines (according to wc) 1477 lines of code (according to D-Scanner) 98 regression tests 11 issues closed in this release 2 ways to spell "color"
Re: [hackathon] One week left to the first D Hackathon!
On 4/19/15 9:03 AM, ANtlord wrote: Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? Yes! The hackathon is exclusively online and distributed! And second question. Will hackaton's projects be published? It's the choice of each author! My hope is that out of this we'll have some good bugfixes, good stuff in http://code.dlang.org, and maybe a good couple of articles. Andrei
Re: Trial migration of Dsource bindings project to Github
On Sunday, 19 April 2015 at 23:37:58 UTC, 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. There's a few on bitbucket.
Nissan recalls 76,000 Rogues
Nissan has issued a recall of the 2014 model Rogue manufactured between June 11, 2013 and June 7, 2014 due to a problem with the fuel pump. In all, the recall affects 76,242 vehicles. According to the National Highway Traffic Safety Administration, the nickel plating on the fuel pump can come loose and bind the impeller which can, over time, cause the car to stall while driving, or not start up at all. Owners of a Nissan Rogue manufactured between the dates listed above can bring in their vehicle to get the defective fuel pump replaced with a new one at no charge. Auto news brought to you by aaaratedinsurance .com Source: autoblog .com/2015/04/10/nissan-recall-76k-rogue-faulty-fuel-pump/ Tags: Nissan Rogue, vehicle recalls, car insurance, auto insurance, insurance quotes
