Re: Release D v2.076.1

2017-10-12 Thread Adam Wilson via Digitalmars-d-announce

On 10/12/17 19:50, Jonathan M Davis wrote:

On Thursday, October 12, 2017 14:39:27 b4s1L3 via Digitalmars-d-announce
wrote:

Also i'd like to say that the policy that is that regression
fixes are commited on stable and that the fact that they only
come to master in a "sync operation" is a problem.

In the travis yaml we have to test dmd, dmd beta (stable, not yet
released) and finally dmd master (current working tree). The
policy should be changed so that regression fixes are commited to
both master and stable, allowing to decrease the CI complexity.

The problem is mainly that testing a project with dmd beta is
pointless. It's only useful 1 or 2 weeks before a release, which
happens , let's say, 4 times per years, leading to a waste of
computing resources at the CI service.

With reg fixes put in master at the same time that in stable,
testing 3 versions of the DMD compiler would not be necessary
anymore, i think.


I don't know what the best way to handle committing regression fixes is, but
I did find it annoying recently when I ran into a bug on master that I'd
fixed on stable, but the fix hadn't been merged over yet. The fact that the
fixes are delayed on master makes master buggier than it would be otherwise,
and a number of us use master as our primary compiler.

- Jonathan M Davis



At work we branch out of stable (not yet released) and fix the bug. 
Merge branch to stable and then merge branch to master. Works pretty 
well. As long as you don't merge things into stable that you never 
intend for master.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;


Re: Release D v2.076.1

2017-10-12 Thread Jonathan M Davis via Digitalmars-d-announce
On Thursday, October 12, 2017 14:39:27 b4s1L3 via Digitalmars-d-announce 
wrote:
> Also i'd like to say that the policy that is that regression
> fixes are commited on stable and that the fact that they only
> come to master in a "sync operation" is a problem.
>
> In the travis yaml we have to test dmd, dmd beta (stable, not yet
> released) and finally dmd master (current working tree). The
> policy should be changed so that regression fixes are commited to
> both master and stable, allowing to decrease the CI complexity.
>
> The problem is mainly that testing a project with dmd beta is
> pointless. It's only useful 1 or 2 weeks before a release, which
> happens , let's say, 4 times per years, leading to a waste of
> computing resources at the CI service.
>
> With reg fixes put in master at the same time that in stable,
> testing 3 versions of the DMD compiler would not be necessary
> anymore, i think.

I don't know what the best way to handle committing regression fixes is, but
I did find it annoying recently when I ran into a bug on master that I'd
fixed on stable, but the fix hadn't been merged over yet. The fact that the
fixes are delayed on master makes master buggier than it would be otherwise,
and a number of us use master as our primary compiler.

- Jonathan M Davis



Re: iopipe alpha 0.0.1 version

2017-10-12 Thread Steven Schveighoffer via Digitalmars-d-announce

On 10/12/17 3:05 AM, Jacob Carlborg wrote:

On 2017-10-12 06:22, Steven Schveighoffer wrote:

I also want to add generated documentation. Does anyone know of a good 
way to generate the ddoc (or ddox or whatever) and put it directly 
into the repository for github to serve? Would be an awesome tip for 
people making projects for code.dlang.org.


I would suggest using GitHub Pages [1] for storing it.

[1] https://pages.github.com



Thanks, I used dub -b ddox to generate the documentation, then committed 
the result, looks great!


http://schveiguy.github.io/iopipe

Release 0.0.2 has fixes for the ddoc that I didn't notice before, there 
are no actual changes in the code.


-Steve


Re: Release D v2.076.1

2017-10-12 Thread b4s1L3 via Digitalmars-d-announce

On Thursday, 12 October 2017 at 14:20:42 UTC, b4s1L3 wrote:

On Wednesday, 11 October 2017 at 13:38:10 UTC, b4s1L3 wrote:
On Wednesday, 11 October 2017 at 13:08:38 UTC, Petar Kirov 
[ZombineDev] wrote:

On Wednesday, 11 October 2017 at 10:20:01 UTC, b4s1L3 wrote:
On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak 
wrote:

Glad to announce D v2.076.1.

http://dlang.org/download.html

This point release fixes a few issues over v2.076.1, see 
the changelog for more details.


http://dlang.org/changelog/v2.076.1.html

- -Martin


I didn't test the beta and missed this regression discovered 
by a CRON at TravisCI:


https://issues.dlang.org/show_bug.cgi?id=17893


Sound like we need more test coverage on the Project Tester 
(https://github.com/dlang/ci/blob/master/pipeline.groovy#L319).


The regression was discovered in iz, which was at least 
another time "victim" of a regression (almost day for day 1 
year ago). https://github.com/BBasile/iz.


This time it is trivial to overcome. It happens in a contract 
so checking for a version number does the job and the release 
version is not affected at all.


I can still add dmd beta as D Compiler in the CI. I think that 
iz occasionally breaks because it covers many programming 
style, not because of its "edginess", which means that's its 
probably not worth adding it to the Project tester.


Also i'd like to say that the policy that is that regression 
fixes are commited on stable and that the fact that they only 
come to master in a "sync operation" is a problem.


In the travis yaml we have to test dmd, dmd beta (stable, not yet 
released) and finally dmd master (current working tree). The 
policy should be changed so that regression fixes are commited to 
both master and stable, allowing to decrease the CI complexity.


The problem is mainly that testing a project with dmd beta is 
pointless. It's only useful 1 or 2 weeks before a release, which 
happens , let's say, 4 times per years, leading to a waste of 
computing resources at the CI service.


With reg fixes put in master at the same time that in stable, 
testing 3 versions of the DMD compiler would not be necessary 
anymore, i think.


Re: Release D v2.076.1

2017-10-12 Thread b4s1L3 via Digitalmars-d-announce

On Wednesday, 11 October 2017 at 13:38:10 UTC, b4s1L3 wrote:
On Wednesday, 11 October 2017 at 13:08:38 UTC, Petar Kirov 
[ZombineDev] wrote:

On Wednesday, 11 October 2017 at 10:20:01 UTC, b4s1L3 wrote:

On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote:

Glad to announce D v2.076.1.

http://dlang.org/download.html

This point release fixes a few issues over v2.076.1, see the 
changelog for more details.


http://dlang.org/changelog/v2.076.1.html

- -Martin


I didn't test the beta and missed this regression discovered 
by a CRON at TravisCI:


https://issues.dlang.org/show_bug.cgi?id=17893


Sound like we need more test coverage on the Project Tester 
(https://github.com/dlang/ci/blob/master/pipeline.groovy#L319).


The regression was discovered in iz, which was at least another 
time "victim" of a regression (almost day for day 1 year ago). 
https://github.com/BBasile/iz.


This time it is trivial to overcome. It happens in a contract 
so checking for a version number does the job and the release 
version is not affected at all.


I can still add dmd beta as D Compiler in the CI. I think that iz 
occasionally breaks because it covers many programming style, not 
because of its "edginess", which means that's its probably not 
worth adding it to the Project tester.


Re: iopipe alpha 0.0.1 version

2017-10-12 Thread Steven Schveighoffer via Digitalmars-d-announce

On 10/12/17 1:48 AM, Dmitry Olshansky wrote:

On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote:
I added a tag for iopipe and added it to the dub registry so people 
can try it out.


I didn't want to add it until I had fully documented and unittested it.

http://code.dlang.org/packages/iopipe
https://github.com/schveiguy/iopipe

If you plan on using it, expect some API changes in the near future. I 
think the next step is really to add Windows support for the IODev type.


Might be able to help you on that using WinAPI for I/O. (I assume 
bypassing libc is one of goals).


That would be awesome! Yes, the idea is to avoid any "extra" buffering. 
So using CreateFile, ReadFile, etc.


-Steve



Re: iopipe alpha 0.0.1 version

2017-10-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-10-12 06:22, Steven Schveighoffer wrote:

I also want to add generated documentation. Does anyone know of a good 
way to generate the ddoc (or ddox or whatever) and put it directly into 
the repository for github to serve? Would be an awesome tip for people 
making projects for code.dlang.org.


I would suggest using GitHub Pages [1] for storing it.

[1] https://pages.github.com

--
/Jacob Carlborg