- Esug-list - lists.esug.org

Re: [Esug-list] [SPAM] Re: Concurrency Best Practices + Tests

by Nowak, Helge

Dear Noury, I didn’t had the time to do a thorough web search. You certainly did. I found several references that look very promising. Mny of them were concerning Java and OS threads. Othes are about Erlang (https://mariachris.github.io/Pubs/ERLANG-2011.pdf ). I think not only the concurrency problem but also the base technology matters. I couldn’t find anything about Smalltalk yet. So you are probably conquering new land. Here is a quote from the preface of “Test Driven Development: By Example” from 2003 by Kent Beck: “There certainly are programming tasks that can’t be driven solely by tests (or, at least not yet). Security and concurrency, for example, are two topics where TDD is insufficient to mechanically demonstrate that the goals of the software has been met.” “Subtle concurrency problems can’t be reliably duplicated by running the code.” Good luck! I am looking forward to your findings. Helge Helge Nowak Cincom Smalltalk Technical Account Manager [http://internal.cincom.com/signature/logo.png]<http://www.cincomsmalltalk.com/> Cincom Systems GmbH & Co. oHG Humboldtstraße 3 60318 Frankfurt am Main GERMANY office mobile website email +49 89 89 66 44 94 +49 172 74 00 402 http://www.cincomsmalltalk.com hnowak(a)cincom.com A standpoint is an intellectual horizon of radius zero. -- Albert Einstein Geschäftsführer/Managing Directors: Thomas M. Nies, Donald E. Vick oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main HRA 50297) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/Ts. HRB 5069) --- CONFIDENTIALITY STATEMENT --- This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. From: Esug-list <esug-list-bounces(a)lists.esug.org> On Behalf Of Noury Bouraqadi Sent: Tuesday, 10 September 2019 15:12 To: Members ESUG <esug-list(a)lists.esug.org> Subject: Re: [Esug-list] [SPAM] Re: Concurrency Best Practices + Tests Thanks you all for your answers. Best, Noury On 7 Sep 2019, at 18:42, James Foster <Smalltalk(a)JGFoster.net<mailto:Smalltalk@JGFoster.net>> wrote: The point of noury is what is the way to approach concurrency when doing TDD. Now how to build reliable …. I won’t pretend to answer such a broad question with anything definitive, but I’d start my investigation of concurrency with a look at databases. One of the primary features of any multi-user database (not just GemStone!) is that transactions are in practice concurrent but the system is designed to apply them as if they were serial and in a way where order does not matter. So I would attempt to identify the concurrent tasks and verify that they each got the result that they would have obtained had they been applied in various serial fashions. Imagine that DrTDD should be extended to support concurrent programming. Then this is the question that we want to get answer. I would look for a way to pass a set of repeatable tasks to DrTDD and let the testing framework run them in various orders then run them concurrently with interrupts and switching contexts. James _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Sept. 10, 2019

Re: [Esug-list] [SPAM] Re: Concurrency Best Practices + Tests

by Noury Bouraqadi

Thanks you all for your answers. Best, Noury > On 7 Sep 2019, at 18:42, James Foster <Smalltalk(a)JGFoster.net> wrote: > > >> The point of noury is what is the way to approach concurrency when doing TDD. >> Now how to build reliable …. > > I won’t pretend to answer such a broad question with anything definitive, but I’d start my investigation of concurrency with a look at databases. One of the primary features of any multi-user database (not just GemStone!) is that transactions are in practice concurrent but the system is designed to apply them as if they were serial and in a way where order does not matter. So I would attempt to identify the concurrent tasks and verify that they each got the result that they would have obtained had they been applied in various serial fashions. > >> Imagine that DrTDD should be extended to support concurrent programming. >> Then this is the question that we want to get answer. > > I would look for a way to pass a set of repeatable tasks to DrTDD and let the testing framework run them in various orders then run them concurrently with interrupts and switching contexts. > > James > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Sept. 10, 2019

Smalltalk and the list of popular programming languages

by David Mason

I don’t want to fall too far down the language popularity rabbit-hole, but I think it is worth seeing if Pharo Smalltalk has a viable story. I’m most interested in how we compare with Python, in particular: "Python’s popularity is driven in no small part by the vast number of specialized libraries available for it, particularly in the domain of artificial intelligence, where the Keras library is a heavyweight among deep-learning developers: Keras provides an interface to the TensorFlow, CNTK, and Theano deep-learning frameworks and tool kits.” and: "dramatic increase in computing power found in microcontrollers means that embedded versions of Python, such as CircuitPython and MicroPython, are becoming increasingly popular among makers.” I’d love to be able to say, when people challenge me about Smalltalk, that we have those, or the logical equivalent of this. ../Dave

Sept. 9, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Stéphane Ducasse

> > On 9/7/19 9:03 , Stéphane Ducasse wrote: >> Again and now this is you: why do you use “sharper” do you imply that the >> questions of noury were not sharp. :( > > No, I didn't say that either --- "sharper", not "sharp vs dull”. At least in french, when we say that "a better/sharper question would be" it implies that previous question was not sharp/smart. May be in english this is not the case, I’m sorry my english is rather basic. I thought that adding “er” at the end of adjective meant more. So by construction it means that other are less. I do not know I’m not good in logic either. May be you do see it but I felt that you were saying that and this is why I reacted because I do not like when people lower other people in this mailing-list. Of course I could have say using the same pattern, that a nicer/smarter/shaper answer would have been not to show off and to reply to the question. And when another person would have mentioned it, I would have decline my intention. >> The point of noury is what is the way to approach concurrency when doing >> TDD. >> Now how to build reliable …. >> >> Imagine that DrTDD should be extended to support concurrent programming. >> Then this is the question that we want to get answer. > > To me, the interesting part is how to build reliable software, so I'd > prioritize that over choice of tools. Because who knows, maybe you look > at reliability and realize instead of TDD you need XYZ. Again, as professional developers and teachers, I believe that we know all that. But thanks for your wisdom. It seemed to me that it was quite a common and basic knowledge. But again this was not the questions. Stef > > Andres. > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 8, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Andres Valloud

On 9/7/19 9:03 , Stéphane Ducasse wrote: > Again and now this is you: why do you use “sharper” do you imply that the > questions of noury were not sharp. :( No, I didn't say that either --- "sharper", not "sharp vs dull". > The point of noury is what is the way to approach concurrency when doing > TDD. > Now how to build reliable …. > > Imagine that DrTDD should be extended to support concurrent programming. > Then this is the question that we want to get answer. To me, the interesting part is how to build reliable software, so I'd prioritize that over choice of tools. Because who knows, maybe you look at reliability and realize instead of TDD you need XYZ. Andres.

Sept. 7, 2019

Re: [Esug-list] [SPAM] Re: Concurrency Best Practices + Tests

by James Foster

> The point of noury is what is the way to approach concurrency when doing TDD. > Now how to build reliable …. I won’t pretend to answer such a broad question with anything definitive, but I’d start my investigation of concurrency with a look at databases. One of the primary features of any multi-user database (not just GemStone!) is that transactions are in practice concurrent but the system is designed to apply them as if they were serial and in a way where order does not matter. So I would attempt to identify the concurrent tasks and verify that they each got the result that they would have obtained had they been applied in various serial fashions. > Imagine that DrTDD should be extended to support concurrent programming. > Then this is the question that we want to get answer. I would look for a way to pass a set of repeatable tasks to DrTDD and let the testing framework run them in various orders then run them concurrently with interrupts and switching contexts. James

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Stéphane Ducasse

> On 7 Sep 2019, at 10:42, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > > On 9/6/19 23:24 , Stéphane Ducasse wrote: >> Now it would be nice to read his questions and reply to them and not >> just tell him “oh do not use concurrency” > > I did not say that at all --- yet you are complaining to me :). Not to you in particular. To everybody :) >> The questions are essentially how do we test? how does concurrent >> programming fit in TDD. > > A sharper and more open minded question might be "what is the best way > to build reliable programs using concurrency flavor XYZ?”. No you see you are interpreting the questions of Noury. Again and now this is you: why do you use “sharper” do you imply that the questions of noury were not sharp. :( The point of noury is what is the way to approach concurrency when doing TDD. Now how to build reliable …. Imagine that DrTDD should be extended to support concurrent programming. Then this is the question that we want to get answer. Stef >> Stef >> >>> On 6 Sep 2019, at 02:32, Andres Valloud >>> <avalloud(a)smalltalk.comcastbiz.net <mailto:avalloud@smalltalk.comcastbiz.net> >>> <mailto:avalloud@smalltalk.comcastbiz.net <mailto:avalloud@smalltalk.comcastbiz.net>>> wrote: >>> >>> TL; DR: generally, developing a good sense of what to do ***before >>> writing a single line of code*** works really well. >>> >>> On 9/4/19 6:32 , N. Bouraqadi wrote: >>>> Hi everyone, >>>> >>>> Can I get your input on the following questions : >>>> >>>> - What are your best practices and recommendations for developing and >>>> testing concurrent software? >>>> >>>> - How to discover need for synchronization/critical sections/ when >>>> doing TDD? >>>> >>>> - How to write code to avoid dead-locks? >>>> >>>> Thanks for your help, >>>> Noury >>>> _______________________________________________ >>>> Esug-list mailing list >>>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> <mailto:Esug-list@lists.esug.org <mailto:Esug-list@lists.esug.org>> >>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> >>>> . >>>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> <mailto:Esug-list@lists.esug.org <mailto:Esug-list@lists.esug.org>> >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> -------------------------------------------- >> Stéphane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> >> > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Giovanni Corriga

Some random thoughts: 1) model your concurrency problem before you start with TDD, e.g. using TLA+. This will make clear what you need to implement using TDD. 2) once you have a satisfying result from 1, you can start designing your solution using TDD. Of the tests that you will need to write: - some will be pure behaviour tests which don’t to worry about concurrency - some will be coordination tests were you need to worry about concurrency. The coordination tests can be approached as simulation problems, where you can manage the choreography of the various concurrent processes. To do this: A) model your concurrent operation as transactions. Split the transaction execution into smaller steps, that can be tested separately. You can then set up a sequence of operations coming from multiple processes, interleaving ops from one process with those from the others. This will also make it easier to understand where to use coordination primitives. B) Explicitly manage the evaluation of the code in the two processes. You can do this with a creative use of method wrappers, Delay objects etc., or by forcing the code to run through a debugger, so that can manage the order of the message sends between the processes Please also note that TDD might not be enough and you might need to run other type of tests than TDD-style unit tests. Cheers, Giovanni Il giorno sab 7 set 2019 alle 03:25 Stéphane Ducasse < stephane.ducasse(a)inria.fr> ha scritto: > Hi guys > > I imagine that noury knows most of the remarks you sent it. > He is far from dull. > Now it would be nice to read his questions and reply to them and not just > tell him > “oh do not use concurrency” > > The questions are essentially how do we test? how does concurrent > programming fit in TDD. > > Stef > > > On 6 Sep 2019, at 02:32, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> > wrote: > > TL; DR: generally, developing a good sense of what to do ***before > writing a single line of code*** works really well. > > On 9/4/19 6:32 , N. Bouraqadi wrote: > > Hi everyone, > > Can I get your input on the following questions : > > - What are your best practices and recommendations for developing and > testing concurrent software? > > - How to discover need for synchronization/critical sections/ when doing > TDD? > > - How to write code to avoid dead-locks? > > Thanks for your help, > Noury > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > . > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley > <https://www.google.com/maps/search/40,+avenue+Halley?entry=gmail&source=g> > , > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Joachim Tuchel

I think the question was if there are any patterns or best practices to identify potential concurrency issues that could be used to build tools... maybe that’s why Complaints occurred...? > Am 07.09.2019 um 10:42 schrieb Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > >> On 9/6/19 23:24 , Stéphane Ducasse wrote: >> Now it would be nice to read his questions and reply to them and not >> just tell him “oh do not use concurrency” > > I did not say that at all --- yet you are complaining to me :). > >> The questions are essentially how do we test? how does concurrent >> programming fit in TDD. > > A sharper and more open minded question might be "what is the best way > to build reliable programs using concurrency flavor XYZ?". > > Andres. > >> >> Stef >> >>> On 6 Sep 2019, at 02:32, Andres Valloud >>> <avalloud(a)smalltalk.comcastbiz.net >>> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >>> >>> TL; DR: generally, developing a good sense of what to do ***before >>> writing a single line of code*** works really well. >>> >>>> On 9/4/19 6:32 , N. Bouraqadi wrote: >>>> Hi everyone, >>>> >>>> Can I get your input on the following questions : >>>> >>>> - What are your best practices and recommendations for developing and >>>> testing concurrent software? >>>> >>>> - How to discover need for synchronization/critical sections/ when >>>> doing TDD? >>>> >>>> - How to write code to avoid dead-locks? >>>> >>>> Thanks for your help, >>>> Noury >>>> _______________________________________________ >>>> Esug-list mailing list >>>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >>>> . >>>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> -------------------------------------------- >> Stéphane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Andres Valloud

On 9/6/19 23:24 , Stéphane Ducasse wrote: > Now it would be nice to read his questions and reply to them and not > just tell him “oh do not use concurrency” I did not say that at all --- yet you are complaining to me :). > The questions are essentially how do we test? how does concurrent > programming fit in TDD. A sharper and more open minded question might be "what is the best way to build reliable programs using concurrency flavor XYZ?". Andres. > > Stef > >> On 6 Sep 2019, at 02:32, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net >> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >> >> TL; DR: generally, developing a good sense of what to do ***before >> writing a single line of code*** works really well. >> >> On 9/4/19 6:32 , N. Bouraqadi wrote: >>> Hi everyone, >>> >>> Can I get your input on the following questions : >>> >>> - What are your best practices and recommendations for developing and >>> testing concurrent software? >>> >>> - How to discover need for synchronization/critical sections/ when >>> doing TDD? >>> >>> - How to write code to avoid dead-locks? >>> >>> Thanks for your help, >>> Noury >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >>> . >>> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 7, 2019