By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl) has been accepted into Phobos.  Thanks to Jonas for his hard work and his persistence through the multiple rounds of review that it took to get this module up to Phobos's high and increasing quality standard.

Keep the good work coming.  Next in line, if it's ready, is Jacob Carlborg's std.serialize.  Jacob, please post here when you've got something ready to go.

On Tuesday, 27 December 2011 at 02:01:51 UTC, dsimcha wrote:
> By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl) has been accepted into Phobos.  Thanks to Jonas for his hard work and his persistence through the multiple rounds of review that it took to get this module up to Phobos's high and increasing quality standard.
>
> Keep the good work coming.  Next in line, if it's ready, is Jacob Carlborg's std.serialize.  Jacob, please post here when you've got something ready to go.

I'll go fix the last issues mentioned in the final review thread and the do a pull request.

Thanks to all who provided valuable feedback.

On 2011-12-27 03:01, dsimcha wrote:
> By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl) has been
> accepted into Phobos. Thanks to Jonas for his hard work and his
> persistence through the multiple rounds of review that it took to get
> this module up to Phobos's high and increasing quality standard.
>
> Keep the good work coming. Next in line, if it's ready, is Jacob
> Carlborg's std.serialize. Jacob, please post here when you've got
> something ready to go.

Project page (two tutorials): http://dsource.org/projects/orange
Repository: https://github.com/jacob-carlborg/orange

Documentation:

http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializer.html

(Don't forget the "Package" tab)

Unit tests are available in the "tests" directory. These unit tests are not like regular unit tests that test individual functions. These unit tests are on a higher level.

The most important part to review is the "serialization" package. The rest is mostly utility modules.

Running the unit tests:
./unittest.sh

Use "make" to compile the library or create an executable using rdmd.

A few things to think about that need to be resolved:

* This is quite a large library and I really don't want to put it all into one module. I'm hoping it will be OK with a package

* I would really like to keep the unit tests in their own modules because they're quite large and the modules are already large without the unit tests in them

* The unit tests use a kind of mini-unit test framework. Should that be kept or removed?

Note:

The documentation is generate using D1, I don't think that should make a difference though.

-- 
/Jacob Carlborg

On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg wrote:
> Running the unit tests:
> ./unittest.sh
>
> Use "make" to compile the library or create an executable using rdmd.
>
> A few things to think about that need to be resolved:
>
> * This is quite a large library and I really don't want to put it all into one module. I'm hoping it will be OK with a package

So the package would be std.serialize?

>
> * I would really like to keep the unit tests in their own modules because they're quite large and the modules are already large without the unit tests in them

Sounds reasonable.  It goes against the Phobos convention, but it sounds like you have a good reason to.

>
> * The unit tests use a kind of mini-unit test framework. Should that be kept or removed?

I haven't looked at it yet, but if it's generally useful, maybe it should be extracted and exposed as part of Phobos.  I'd say keep it for now but keep it private, and later make a proposal for a full review to make it a public, official part of Phobos.

>
> Note:
>
> The documentation is generate using D1, I don't think that should make a difference though.

On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg wrote:
> On 2011-12-27 03:01, dsimcha wrote:
>> By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl) has been
>> accepted into Phobos. Thanks to Jonas for his hard work and his
>> persistence through the multiple rounds of review that it took to get
>> this module up to Phobos's high and increasing quality standard.
>>
>> Keep the good work coming. Next in line, if it's ready, is Jacob
>> Carlborg's std.serialize. Jacob, please post here when you've got
>> something ready to go.
>
> Project page (two tutorials): http://dsource.org/projects/orange
> Repository: https://github.com/jacob-carlborg/orange
>
> Documentation:
>
> http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializer.html
>
> (Don't forget the "Package" tab)
>
> Unit tests are available in the "tests" directory. These unit tests are not like regular unit tests that test individual functions. These unit tests are on a higher level.
>
> The most important part to review is the "serialization" package. The rest is mostly utility modules.

After I quick look:

I think that all other modules/packages under the orange package should either be integrated into other existing phobos modules or as new
phobos modules since they are really not serialization specific.

Furthermore I think that all suppport for tango in the code should be stripped before going into phobos.

/Jonas

On 2011-12-28 19:43, dsimcha wrote:
> On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg wrote:
>> Running the unit tests:
>> ./unittest.sh
>>
>> Use "make" to compile the library or create an executable using rdmd.
>>
>> A few things to think about that need to be resolved:
>>
>> * This is quite a large library and I really don't want to put it all
>> into one module. I'm hoping it will be OK with a package
>
> So the package would be std.serialize?

Yeah, or std.serialization.

>>
>> * I would really like to keep the unit tests in their own modules
>> because they're quite large and the modules are already large without
>> the unit tests in them
>
> Sounds reasonable. It goes against the Phobos convention, but it sounds
> like you have a good reason to.
>
>>
>> * The unit tests use a kind of mini-unit test framework. Should that
>> be kept or removed?
>
> I haven't looked at it yet, but if it's generally useful, maybe it
> should be extracted and exposed as part of Phobos. I'd say keep it for
> now but keep it private, and later make a proposal for a full review to
> make it a public, official part of Phobos.

I think it is, don't know what others think. What it does is it catches AssertErrors so other unit tests can continue to run and then gives a nice report at the end.

-- 
/Jacob Carlborg

On 2011-12-28 22:19, jdrewsen wrote:
> On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg wrote:
>> On 2011-12-27 03:01, dsimcha wrote:
>>> By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl) has been
>>> accepted into Phobos. Thanks to Jonas for his hard work and his
>>> persistence through the multiple rounds of review that it took to get
>>> this module up to Phobos's high and increasing quality standard.
>>>
>>> Keep the good work coming. Next in line, if it's ready, is Jacob
>>> Carlborg's std.serialize. Jacob, please post here when you've got
>>> something ready to go.
>>
>> Project page (two tutorials): http://dsource.org/projects/orange
>> Repository: https://github.com/jacob-carlborg/orange
>>
>> Documentation:
>>
>> http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializer.html
>>
>>
>> (Don't forget the "Package" tab)
>>
>> Unit tests are available in the "tests" directory. These unit tests
>> are not like regular unit tests that test individual functions. These
>> unit tests are on a higher level.
>>
>> The most important part to review is the "serialization" package. The
>> rest is mostly utility modules.
>
> After I quick look:
>
> I think that all other modules/packages under the orange package should
> either be integrated into other existing phobos modules or as new
> phobos modules since they are really not serialization specific.

I agree with that.

> Furthermore I think that all suppport for tango in the code should be
> stripped before going into phobos.
>
> /Jonas

That is obvious. I don't know if this have been clear or not but I've requested a pre-review. A review that should be as a regular review but before I do a Phobos integration. If it gets accepted into Phobos I'll do the necessary modifications (remove all Tango related code and so on) to integrate it into Phobos and then we can have a second review. I don't want to waste time on removing the Tango support if I don't know for sure that it will be accepted.

-- 
/Jacob Carlborg

On Wednesday, December 28, 2011 23:07:51 Jacob Carlborg wrote:
> I think it is, don't know what others think. What it does is it catches AssertErrors so other unit tests can continue to run and then gives a nice report at the end.

I'm against it. I think that the compiler/runtime should be fixed so that each unit test block is run in a module even if one fails. That would solve the problem quite nicely IMHO, and that's already _supposed_ to be how it works. It just isn't properly implemented in that regard yet. And I'm against unittest blocks running any code after a single failure. So, I don't think that any additional unit testing framework is necessary.

- Jonathan M Davis

On Wed, Dec 28, 2011 at 10:11 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Wednesday, December 28, 2011 23:07:51 Jacob Carlborg wrote:
> > I think it is, don't know what others think. What it does is it catches AssertErrors so other unit tests can continue to run and then gives a nice report at the end.
>
> I'm against it. I think that the compiler/runtime should be fixed so that
> each
> unit test block is run in a module even if one fails. That would solve the
> problem quite nicely IMHO, and that's already _supposed_ to be how it
> works.
> It just isn't properly implemented in that regard yet. And I'm against
> unittest blocks running any code after a single failure. So, I don't think
> that any additional unit testing framework is necessary.
>
> - Jonathan M Davis
>

Forgive me if this is a silly question but a conversation in IRC got me wondering if compiler could check for shared/__gshared use (and any other thread unsafe operation) in each unittest and run those that aren't using them concurrently? Obviously not all at once but at least more than one at a time (perhaps set through user configuration).

Regards,
Brad

On Thursday, 29 December 2011 at 07:07:10 UTC, Brad Anderson wrote:
> Forgive me if this is a silly question but a conversation in IRC got me
> wondering if compiler could check for shared/__gshared use (and any other
> thread unsafe operation) in each unittest and run those that aren't using
> them concurrently? Obviously not all at once but at least more than one at
> a time (perhaps set through user configuration).
>
> Regards,
> Brad

The unittest code can ultimately call into both C and D code which source is not known. Such code would need to cause the unittest to be excluded from concurrent execution, in light of this I think it's questionable if such an analysis would be worth implementing. Perhaps look at some example unittest suites that take a long time and look at whether these examples can be proven to be thread-safe.