|
Brisingr Aerowing wrote: Countered down vote. Why? He posted that as an answer and it clearly is not an answer. He asked questions and should have marked it as such.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Jayamanickam wrote: but it will not run a setup file different sysytem Why won't it?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Hello!
To start off, I'm really new to programming/coding. I know a little but not too much.
So I'm creating a web browser, and I want to add tabs.
What do I have to do to have tabs? What part of the code do I need to post?
Thanks in advance!
|
|
|
|
|
Did you try it with a Tab-Control?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Currently there's no function for tabs. There's simply a button with no code.
I 'simply' need help building this code.
|
|
|
|
|
I assume you currently have a Form and a WebBrowser-Control placed on there, right? To make it multi-tabbed you would have to place a Tab-Control on the Form and WebBrowser-Controls into the Tab-Pages of the Tab-Control. This won't yet automatically allow you to open as many new tabs as you want while running your application but you should do it like this as a first step.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
We are refactoring a component / framework for concurrency testing to fit better in BDD. This is the current project:
http://www.crawler-lib.net/crawler-lib-concurrency-testing
We want to have a more fluent API that fits better in BDD scenarios with Given/When/Then.
Do you test concurrency in your unit tests or would you like to? Please give us information how you do this now and how you want it. Thanks
|
|
|
|
|
I usually test the work that the thread has to execute, not the threaded environment. I try to keep the units that are tested as small and simple as possible, otherwise it'd be crawling with (threading) dependencies making testing too complex or even impossible.
Some good tips can be found here;
http://www.alexecollins.com/5-tips-unit-testing-threaded-code/
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Example: If you develop a Reader/Writer Lock component (I know this class exists already, but for the understanding), you can't test the component without threads. The synchronization mechanism is the essential behavior of this component.
The article you mentioned uses a Java framework with essentially the same approach what we have developed now. They name it "Executors" but this is not the point. We are far beyond that. For now we want a framework that can be used for BDD in a more elegant way.
These are fragments from the ConcurrencyTester we are developing now. In fact it is a BDD Test with BDDfy, NUnit and Shoudy testing the .NET ReaderWriterLock (as a sample):
[Test]
public void MultipleReaders()
{
using (concurrencyTester = new ConcurrencyTester())
{
this.Given(c => c.new_reader_writer_lock())
.And(c => c.i_start_read_operation(1))
.And(c => c.i_wait_till_read_operation_is_pending(1))
.And(c => c.i_start_write_operation(1))
.And(c => c.i_start_read_operation(2))
.And(c => c.i_wait_till_read_operation_is_pending(2))
.And(c => c.i_start_write_operation(2))
.When(c => c.release_read_operations(new[] { 1, 2 }))
.And(c => c.release_write_operations(new[] { 1, 2 }))
.And(c => c.wait_for_test_end())
.Then(c => c.write_operations_should_not_intersect_with_read_operations())
.And(c => c.write_operations_should_not_intersect_with_other_write_operations())
.BDDfy();
concurrencyTester.Marks.DumpTimeline();
}
}
In the user story scenario it uses steps like:
void i_start_write_operation(int number)
{
concurrencyTester.Start(
c =>
{
readerWriterLock.EnterWriteLock();
using (concurrencyTester.Marks["Write"].BeginSection())
{
concurrencyTester.Events[WriteOperationPending, number].Wait();
}
readerWriterLock.ExitWriteLock();
}, "Write Operation #{0}", number);
}
To describe things on a different thread.
After the test run has ended (we are multi threaded) we check what should be and what not:
void write_operations_should_not_intersect_with_read_operations()
{
foreach (var intersect in this.concurrencyTester.Marks["Write"].Sections.SelectMany(readSection => readSection.Relations.Intersect))
{
intersect.Mark.Name.ShouldNotBe("Read");
}
}
So it should become very easy to write concurrency tests with this framework. I'm now interested in test cases where concurrency / multi threaded tests are needed.
|
|
|
|
|
Thomas Maierhofer (Tom) wrote: this.Given(c => c.new_reader_writer_lock())
.And(c => c.i_start_read_operation(1))
.And(c => c.i_wait_till_read_operation_is_pending(1))
.And(c => c.i_start_write_operation(1))
.And(c => c.i_start_read_operation(2))
.And(c => c.i_wait_till_read_operation_is_pending(2))
.And(c => c.i_start_write_operation(2))
.When(c => c.release_read_operations(new[] { 1, 2 }))
.And(c => c.release_write_operations(new[] { 1, 2 }))
.And(c => c.wait_for_test_end())
.Then(c => c.write_operations_should_not_intersect_with_read_operations())
.And(c => c.write_operations_should_not_intersect_with_other_write_operations())
.BDDfy();
What does the "fluent" part add? Looks like merely a wrapper around each statement, and not helping much in terms of readability. In fact, looks more like "everything" is wrapped in a local method with a very long name.
Thomas Maierhofer (Tom) wrote: So it should become very easy to write concurrency tests with this framework I'd love to see an in-depth article on the subject
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The long method names are extracted by BDDfy to generate the test documentation:
http://docs.teststack.net/bddfy/
Behavior Driven Tests have all the same structure:
Given(...)
When( ... )
Then( ... )
Our old approach of concurrency testing does not fit in very well:
Test.Run(...)
Assert( Test.Is...)
You can't split this up semantically in Given/When/Then
The new approach is better:
Given ...
When ...
And I start write operation #1
is just a fluent Add() of this method:
.And(c => c.i_start_write_operation(1))
void i_start_write_operation(int number)
{
concurrencyTester.Start(
c =>
{
readerWriterLock.EnterWriteLock();
using (concurrencyTester.Marks["Write"].BeginSection())
{
concurrencyTester.Events[WriteOperationPending, number].Wait();
}
readerWriterLock.ExitWriteLock();
}, "Write Operation #{0}", number);
}
The execution of this test is controlled outside with the events:
void release_write_operations(int[] numbers)
{
foreach (var number in numbers)
{
concurrencyTester.Events[WriteOperationPending, number].Set();
}
}
This is the point in the test where the operations are released:
.When(c => c.release_read_operations(new[] { 1, 2 }))
.And(c => c.release_write_operations(new[] { 1, 2 }))
After that we can check what happens. The sections in the Marks collection are recorded and the relations Before, Intersect and After are queryable. So it is simple to express that the Read Sections should not intersect with the write sections.
This is the Timeline Dump of this test (EP means execution path):
Timeline Dump:
EP[0] Read-Enter
EP[2] Read-Enter
EP[2] Read-Leave
EP[0] Read-Leave
EP[1] Write-Enter
EP[1] Write-Leave
EP[3] Write-Enter
EP[3] Write-Leave
The first read on EP0 intersects with the second read on EP2, this is ok because multiple readers are allowed.
The first Write on EP1 is delayed until all reads are complete
The second Write on EP3 is delayed until the first read completes, this is OK, because only one writer is allowed.
Without the concurrency tester this is much harder to test.
|
|
|
|
|
Thomas Maierhofer (Tom) wrote: Behavior Driven Tests have all the same structure: Thanks for the link; I don't have any specific experience with BDT.
Thomas Maierhofer (Tom) wrote: Our old approach of concurrency testing does not fit in very well: I don't see the difference; either you .And(bla) or Assert(bla). As soon as it is repeated on each line, it becomes noise during reading.
Thomas Maierhofer (Tom) wrote: You can't split this up semantically in Given/When/Then Indeed, I usually start with mocking input and checking whether I get the expected output.
Thomas Maierhofer (Tom) wrote: Without the concurrency tester this is much harder to test. The only thing you wouldn't have is the path of the threads that are depending on another - that's the kind of dependency I try to avoid altogether.
Seriously, I would love an article; you sound like you know the subject very well, and I feel I must be blinded by my old habits (or defend them too much) to see the obvious advantages.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: The only thing you wouldn't have is the path of the threads that are depending on another - that's the kind of dependency I try to avoid altogether.
If I want to test a synchronization primitive - here a Reader Writer lock, how can you avoid thread dependencies? It is all about the behavior on different threads, because that is what synchronization primitives do. Imagine a unit test (in pseudocode) that can perform the same test from scratch. How this may look like?
Quote: Thomas Maierhofer (Tom) wrote:
Our old approach of concurrency testing does not fit in very well: I don't see the difference; either you .And(bla) or Assert(bla). As soon as it is repeated on each line, it becomes noise during reading.
Maybe so you're just writing unit tests or maybe you are doing a little TDD. BDD is a slightly different approach. Love it or hate it.
In fact the ConcurrencyTester should work well in TDD and BDD scenarios.
|
|
|
|
|
Thomas Maierhofer (Tom) wrote: If I want to test a synchronization primitive - here a Reader Writer lock, how
can you avoid thread dependencies? There's no silver bullet there, no single solution that will work in all cases. Instead of waiting for the reader-thread you might want to look at a queue.
Thomas Maierhofer (Tom) wrote: Imagine a unit test (in pseudocode) that can perform the same test from scratch. It would be testing whether the story as written works under the current conditions. How does it work if there's a deadlock because no reader-thread can be started (say, because someone is writing to the locked file)?
Thomas Maierhofer (Tom) wrote: BDD is a slightly different approach. Love it or hate it. I can't do either until I know it a bit better.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote:
Thomas Maierhofer (Tom) wrote:
If I want to test a synchronization primitive - here a Reader Writer lock, how
can you avoid thread dependencies?There's no silver bullet there, no single solution that will work in all cases. Instead of waiting for the reader-thread you might want to look at a queue.
Sorry you totally misunderstood me. If you are DEVELOPING a Reader Writer Lock Class, how could you possibly test YOR OWN Reader Writer Lock Class without threads? There is no queue, YOU are developing a Reader Writer Lock Class.
|
|
|
|
|
Thomas Maierhofer (Tom) wrote: Sorry you totally misunderstood me. If you are DEVELOPING a Reader Writer Lock
Class I did not misunderstand; I would not have them in a single class.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
Thomas Maierhofer (Tom) wrote: Assuming I am the guy who developed this class, how would I test this class? Thouroughly, I hope.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hello guys. How do I send my slave application (in windows forms) multiple commands ? I am trying to show frame rate and video bitrate using two commands in mplayer (running as a slave app in windows form). Bit it shows only one things at a time, alternately. Here is what I am trying
objPlayerProcess.StandardInput.WriteLine("osd_show_property_text ${fps}" + "(FrameRate)");
objPlayerProcess.StandardInput.WriteLine(objPlayerProcess.StandardInput.NewLine);
objPlayerProcess.StandardInput.WriteLine("osd_show_property_text ${video_bitrate}" + "(BitRate)");
How do I show both of them, at the same time ? Thanks for any input.
|
|
|
|
|
There's nothing wrong with the code you're showing here other than I can't see how ${fps} and ${video_bitrate} should be replaced by some value. The actual problem is probably located in your receiving code or display code.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Sascha Lefévre wrote: .... other than I can't see how ${fps} and ${video_bitrate} should be replaced by some value.
Yes. Those will be handled by the player internally. Again, values are being shown but...one by one. Not at the same time.
|
|
|
|
|
With the second sentence of my previous reply I tried to hint at you that you need to provide more information / code
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
The slave application will be receiving them one by one. If you want to send them together, then make a single line of it, or change the slave to accept multiple arguments and wait with processing until there's a "I'm done sending stuff" command.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I tried to send them in single line like this ...
objPlayerProcess.StandardInput.WriteLine("osd_show_property_text ${fps}" + "(FrameRate)" + objPlayerProcess.StandardInput.NewLine + "osd_show_property_text ${video_bitrate}" + "(BitRate)");
I don't know if there exists another method. This did not work either. It shows them alternately.
|
|
|
|