View mode: basic / threaded / horizontal-split · Log in · Help
December 27, 2011
CURL Wrapper: Congratulations Next up: std.serialize
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.
December 27, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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.
December 28, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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
December 28, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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.
December 28, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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
December 28, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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
December 28, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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
December 29, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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
December 29, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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
December 29, 2011
Re: CURL Wrapper: Congratulations Next up: std.serialize
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home