November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Does Pharo stores original author of methods?

by Thierry Goubier

Le 30 nov. 2015 5:24 AM, "EuanM" <euanmee(a)gmail.com> a Ã©crit : > > Is there anything stopping us adding one more dictionary to each > Monticello commit? > > A key of commit ids and values of author name? This dictionary is already there in the version metadata... The file that generates conflicts in git. Thierry > On 24 November 2015 at 06:55, stepharo <stepharo(a)free.fr> wrote: > > +1 > > > > And so far Monticello is much better that having delta because you can still > > get a complete project without having to reconstruct the complete > > snapshot from deltas. I could not imagine the amount of code we would have > > lost else. > > Veronica in her PhD built a crawler that reconstructs all the deltas based > > on MC files. Now this is work. > > Stef > > > > Le 23/11/15 17:02, Nicolas Cellier a Ã©crit : > > > > It's not Monticello per se. It's the backend (the server) which is too > > naive. > > The .mcz must be considered as a unit of exchange between the server (the > > repository) and the client (the working copy). And please note that in > > Monticello, it's not the only way to exchange data, it can also be a .mcd (a > > diff). > > > > Nothing forces the server to store the .mcz as is. That's just a naive > > implementation. Chris Muller demonstrated how to use a database (magma) as > > backend... > > > > 2015-11-23 12:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> > >> > >> > On 22 Nov 2015, at 20:12, EuanM <euanmee(a)gmail.com> wrote: > >> > > >> > Is there any reason against amending Monticello to store and save all > >> > author's names? > >> > >> It does. *If* you have all the versionsâ¦ but doing anything with âall the > >> versionsâ > >> is so slow (you need to download them, unpack themâ¦) that we do not even > >> have > >> a tool to show the history of a method. > >> (getting the oldest should be simpler, if you have complete history+this > >> .mcz is > >> there). > >> > >> Monticello is meant to be a system to save the complete history of a > >> project > >> (if you keep all the MCZ available), but the idea to save every tiny > >> revision as > >> a complete snapshot, zip compresses, makes it near impossible to do > >> anything > >> with the history in practice. > >> > >> With today disks, a practical SCM would allow anyone to have the > >> *complete* > >> history on the local disk. Monticello does now allow that in any practical > >> way. > >> > >> > > >> > Presumably, we'd also want a tool that could extract amnders' names > >> > all the way back to the first commit of a package? > >> > > >> > How many on-line Monticello repositories are in common use? > >> > > >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) > >> > > >> > Are there active administrators for each of those repositories that > >> > would allow us to update the repositories to use the updated > >> > Monticello? > >> > > >> > On 22 November 2015 at 15:42, Marcus Denker <marcus.denker(a)inria.fr> > >> > wrote: > >> >> > >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk(a)gmail.com> > >> >> wrote: > >> >> > >> >> > >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >>> > >> >>> epicea data is not stored forever. It is seasion based and the shipped > >> >>> image is > >> >>> clean. > >> >> > >> >> > >> >> But current source of this info is changes file (maybe sources). And I > >> >> remember you planned to store current sources in image. And such > >> >> information > >> >> can be there too. > >> >> Maybe I miss something? > >> >> > >> >> > >> >> The original author is not really that much of information. And storing > >> >> it > >> >> for every method in the image would take space. > >> >> > >> >> As I said: the whole idea of using a source revision control system is > >> >> that > >> >> you have the *complete* history available, but > >> >> not wasting RAM. > >> >> > >> >> Marcus > >> > > >> > >> > > > > >

Nov. 30, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by EuanM

Is there anything stopping us adding one more dictionary to each Monticello commit? A key of commit ids and values of author name? On 24 November 2015 at 06:55, stepharo <stepharo(a)free.fr> wrote: > +1 > > And so far Monticello is much better that having delta because you can still > get a complete project without having to reconstruct the complete > snapshot from deltas. I could not imagine the amount of code we would have > lost else. > Veronica in her PhD built a crawler that reconstructs all the deltas based > on MC files. Now this is work. > Stef > > Le 23/11/15 17:02, Nicolas Cellier a Ã©crit : > > It's not Monticello per se. It's the backend (the server) which is too > naive. > The .mcz must be considered as a unit of exchange between the server (the > repository) and the client (the working copy). And please note that in > Monticello, it's not the only way to exchange data, it can also be a .mcd (a > diff). > > Nothing forces the server to store the .mcz as is. That's just a naive > implementation. Chris Muller demonstrated how to use a database (magma) as > backend... > > 2015-11-23 12:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >> > On 22 Nov 2015, at 20:12, EuanM <euanmee(a)gmail.com> wrote: >> > >> > Is there any reason against amending Monticello to store and save all >> > author's names? >> >> It does. *If* you have all the versionsâ¦ but doing anything with âall the >> versionsâ >> is so slow (you need to download them, unpack themâ¦) that we do not even >> have >> a tool to show the history of a method. >> (getting the oldest should be simpler, if you have complete history+this >> .mcz is >> there). >> >> Monticello is meant to be a system to save the complete history of a >> project >> (if you keep all the MCZ available), but the idea to save every tiny >> revision as >> a complete snapshot, zip compresses, makes it near impossible to do >> anything >> with the history in practice. >> >> With today disks, a practical SCM would allow anyone to have the >> *complete* >> history on the local disk. Monticello does now allow that in any practical >> way. >> >> > >> > Presumably, we'd also want a tool that could extract amnders' names >> > all the way back to the first commit of a package? >> > >> > How many on-line Monticello repositories are in common use? >> > >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >> > >> > Are there active administrators for each of those repositories that >> > would allow us to update the repositories to use the updated >> > Monticello? >> > >> > On 22 November 2015 at 15:42, Marcus Denker <marcus.denker(a)inria.fr> >> > wrote: >> >> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk(a)gmail.com> >> >> wrote: >> >> >> >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >> >>> epicea data is not stored forever. It is seasion based and the shipped >> >>> image is >> >>> clean. >> >> >> >> >> >> But current source of this info is changes file (maybe sources). And I >> >> remember you planned to store current sources in image. And such >> >> information >> >> can be there too. >> >> Maybe I miss something? >> >> >> >> >> >> The original author is not really that much of information. And storing >> >> it >> >> for every method in the image would take space. >> >> >> >> As I said: the whole idea of using a source revision control system is >> >> that >> >> you have the *complete* history available, but >> >> not wasting RAM. >> >> >> >> Marcus >> > >> >> > >

Nov. 30, 2015

Re: [Pharo-dev] red banner and links with safari?

by EuanM

> On 23 November 2015 at 07:24, Stephan Eggermont <stephan(a)stack.nl> wrote: > Why the link to StackOverflow? It is not our data, our community or the possibility to influence the answers. Please delete it. > I'll continue answering questions there, we should not point people there. A link to Stack Overflow is valuable in lots of ways: 1) It is a very good code facility for questions and answers, which is exceptionally searchable via Google Bing et al. Good facilities which we do not need to write or maintain ourselves means that we can focus our effort on other things. There is no reason for us to re-invent a question-and-answer facility, or do the work of keeping it as searchable as a curated site is. 2) Why does it matter who hosts the data? It is freely and publically available, and Stack Exchange are well-funded to keep it that way over the long haul. What benefit does owning the data provide? (My general experience is that trying to control and own data leads to greater data losses over time, compared to putting them in a well-funded public repository. Does the rest of the world use github, or does it builld its own facilities? We don't own the github data. Github is not our community. Do we use Slack, or have we built our own? We don't own the Slack data. Slack is not our community. 3) We certainly *do* have the possibility to influence the answers. If we cannot influence answers to Pharo-specific questions on a public Q&A site, who can? 4) Why Stack Overflow? There was a famous bank robber in the USA who was on the FBIâs list of Ten Most Wanted Fugitives. He was asked by a reporter "Why do you rob banks?" His answer was "Because that's where the money is." Going to where there are valuable resources is a good idea. For us, the most valuable resource is developers. People who develop the Pharo platform and developers who *use* the Pharo platform. At Stack Overflow, we have the opportunity to access the hearts and minds of a *very* large group of developers. We are a very small community, chronically short of developers, documenters, testers, and many other roles. Stack Overflow is a good way to help us encourage people to express interest, and possibly even join us. Stronger, wider, deeper awareness of the benefits of our platform can only help interest in using it. Pharo is not intended as an academic pursuit. It is intended to help make a difference: to the professional lives of developers; to organisations; and to individuals who need a good way of being introduced to OO fundamentals. We make the best difference by making a difference to a large number of people and organisations. We make the best difference if a lot of people help us accelerate the speed of progress and help us complete and maintain and document our feature sets. Cheers, Euan

Nov. 30, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by EuanM

And of course, we can stop doing it manually once threading arrives. On 30 November 2015 at 03:52, EuanM <euanmee(a)gmail.com> wrote: > I have been talking to the Slack dev team and they assure me that > threading is on its way - as a priority. > > I am happy to manually curate threads if someone gets a 24hour dump to > log files working. > > The best way to do this would be to have teams of curators per > channel, each doing a little curation periodically on a rota per > channel basis. > > This is an ideal task for people still getting up to speed with Pharo > internals. It is a great way to be exposed to stuff you don't > understand, and put your mind around it. > > This provide a starter slope for future contributors. > > On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> The problem is, that it is not that easy to create a âdigestâ from Slack, as there is no kind of grouping. Either you have to detect similar words in discussion, or you have to simply export everything. I donât know whether it makes sense to just compose a huge email of all discussions, but we can try to do that. >> >> Cheers. >> Uko >> >>> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: >>> >>> I agree - if we can have each 24 hours of chat archived to somewhere >>> that provides a free-text search, that would be very good. >>> >>> Up until now, I've been grabbing, editting and posting chats I find of >>> interest and importance to me. And it seems to lend itself to design >>> discussions. What it's not very good at, atm, is discussion >>> threading. It would be great to be able to set your typing as >>> belonging to a thread., so that when it get sucked out and archived >>> that the threads were segregated. >>> >>> Does someone have a server that could receive a text dump of all >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it >>> available for indexing by Google et al, and querying (via the search >>> engines) by our dev base? >>> >>> >>> >>> >>> >>> On 22 November 2015 at 13:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>> Just to clear something up , because I see people in slack saying goodbye, >>>> or "I cant reply right now I have something to do" . Slack is not just a >>>> real time chat, it keeps messages inside a history of 10 thousand messages. >>>> So that means you can log in Slack at any time and not lose a message. There >>>> is no reason for you to be online all time, no reason to say goodbye, >>>> goodmorning , goodafternoon. You can come and go as you please the exact >>>> same way as the mailing list. >>>> >>>> The problem arises when we exceed 10k messages, the old ones get lost and I >>>> think having a place to store them is a good idea. >>>> >>>> Also what is important is in the eye of the beholder, for example I dont >>>> care about any discussion about web development , its just does not interest >>>> me or database coding or many other things. I have learned to filter out the >>>> messages I dont care about in the mailing list and just reject them. Slack >>>> is same story, I quickly glance through its history and I can search the >>>> messages that interest me using the search bar , I can star messages that I >>>> want to keep, and I can comment on existing messages / code snippets which >>>> create a thread about that message. >>>> >>>> In the end its impossible to keep the community in one place but to have a >>>> central hub that collects all the little gems can be quite useful. >>>> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Yes this would be good. >>>>> People should understand that important discussions should be via the >>>>> mailing-list. >>>>> Emails are good because you can consume them the way you want. >>>>> I simply cannot be connected all the time. So emails are good because I >>>>> can process them >>>>> when I decide. >>>>> Slack is good for more interactive session around debugger and things >>>>> like that. >>>>> >>>>> Stef >>>>> >>>>> >>>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >>>>>> Should we have a digest from slack to a mailing list? >>>>>> We are already losing messages >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >>

Nov. 30, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by EuanM

I have been talking to the Slack dev team and they assure me that threading is on its way - as a priority. I am happy to manually curate threads if someone gets a 24hour dump to log files working. The best way to do this would be to have teams of curators per channel, each doing a little curation periodically on a rota per channel basis. This is an ideal task for people still getting up to speed with Pharo internals. It is a great way to be exposed to stuff you don't understand, and put your mind around it. This provide a starter slope for future contributors. On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > The problem is, that it is not that easy to create a âdigestâ from Slack, as there is no kind of grouping. Either you have to detect similar words in discussion, or you have to simply export everything. I donât know whether it makes sense to just compose a huge email of all discussions, but we can try to do that. > > Cheers. > Uko > >> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: >> >> I agree - if we can have each 24 hours of chat archived to somewhere >> that provides a free-text search, that would be very good. >> >> Up until now, I've been grabbing, editting and posting chats I find of >> interest and importance to me. And it seems to lend itself to design >> discussions. What it's not very good at, atm, is discussion >> threading. It would be great to be able to set your typing as >> belonging to a thread., so that when it get sucked out and archived >> that the threads were segregated. >> >> Does someone have a server that could receive a text dump of all >> recent Slack messages every 12 (or 24, or 6) hours, and then make it >> available for indexing by Google et al, and querying (via the search >> engines) by our dev base? >> >> >> >> >> >> On 22 November 2015 at 13:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>> Just to clear something up , because I see people in slack saying goodbye, >>> or "I cant reply right now I have something to do" . Slack is not just a >>> real time chat, it keeps messages inside a history of 10 thousand messages. >>> So that means you can log in Slack at any time and not lose a message. There >>> is no reason for you to be online all time, no reason to say goodbye, >>> goodmorning , goodafternoon. You can come and go as you please the exact >>> same way as the mailing list. >>> >>> The problem arises when we exceed 10k messages, the old ones get lost and I >>> think having a place to store them is a good idea. >>> >>> Also what is important is in the eye of the beholder, for example I dont >>> care about any discussion about web development , its just does not interest >>> me or database coding or many other things. I have learned to filter out the >>> messages I dont care about in the mailing list and just reject them. Slack >>> is same story, I quickly glance through its history and I can search the >>> messages that interest me using the search bar , I can star messages that I >>> want to keep, and I can comment on existing messages / code snippets which >>> create a thread about that message. >>> >>> In the end its impossible to keep the community in one place but to have a >>> central hub that collects all the little gems can be quite useful. >>> >>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Yes this would be good. >>>> People should understand that important discussions should be via the >>>> mailing-list. >>>> Emails are good because you can consume them the way you want. >>>> I simply cannot be connected all the time. So emails are good because I >>>> can process them >>>> when I decide. >>>> Slack is good for more interactive session around debugger and things >>>> like that. >>>> >>>> Stef >>>> >>>> >>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >>>>> Should we have a digest from slack to a mailing list? >>>>> We are already losing messages >>>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>> >>>> >>> >> > >

Nov. 30, 2015

Re: [Pharo-dev] Java Future

by EuanM

We also need to concentrate on building our community. We build a better platform faster if we have more people. We build a more valuable platform if we have a wider range of valuable use cases to target. Unless and until we hit a critical mass of people joining our community, we *need* to spend some of our focus on community-building. Part of great is being able to build things to sufficient completeness *and* keep them in working order over the long haul. This is easier with more contributors. On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hello everyone, > > Please stop this thread on this mailing list. We need to focus on building a great platform. > > Cheers, > Doru > > >> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >> >> First of all - is this true? Where can we read about it? >> >> I cannot find anything about this at >> https://www.oracle.com/search/press >> >> ======================================= >> >> If Oracle did make this statement, then what people have said so far >> is true. BUT... >> >> Java got about 40% of its initial momentum from IBM dumping VisualAge >> and putting all their resources into Java. >> >> Oracle are targetting this move at IBM more than anyone else. >> >> IBM will start to think about how to migrate from Java - as Oracle are >> telling them they will have to. (It's OUR bat and its OUR ball, and >> no-one else can play with it. Not even the Java Community). And >> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >> expect the licence-fee income for JREs is small. >> >> Oracle are doing one of two things - announcing that Java is for sale >> to device providers - phones (Google is the obvious buyer) or the >> impending Internet of Things (which was what Java was designed for >> originally) or announcing that no-one making an internet of things >> offering should consider Java. >> >> Yes, things live on and on in a kind of zombie state. So yes, things >> live on as long as their ecosystem does. And they gently wither and >> their ecosystem withers is a long slow drawn out spiral. Which is why >> we still have Cobol. >> >> People and organisations tend to move from one technology to another >> in an incremental fashion. Swapping a little bit here, and a little >> bit there. >> >> The new target platforms are ones which >> 1) look like they have longevity, and >> 2) have a migration pathway that provides incremental steps. >> >> Offering a compelling advantage is good - but only if the steps 1) >> and 2) are catered to. >> >> IBM VisualAge Smalltalk is still robust, commercially available >> software, and VisualStudio and Gemstone continue to represent >> Smalltalk out to the big world of corporate development. >> >> So that's a start. >> >> Say only 5% of the Java world moves away from Java each year, as a >> result of this announcement. >> >> We *should* wish to take advantage of this announcement. >> >> After all, think what difference having even 0.01% of the world's Java >> coders moving to Smalltalk would make. How could we help that >> happen? >> >> Think what it would be like to have thought-leaders like Kent Beck and >> Ward Cunningham back in the Smalltalk fold. How could we help that >> happen? >> >> Think what it would be like to get back all the universities who moved >> from teaching OO concepts using Smalltalk into teaching them via Java. >> We now know almost all the ones using Smalltalk as a teaching language >> by name. Does anyone know even how many universities teach OO via >> Java? What would it be like if 5% of those universities moved to >> Smalltalk each year. How could we help that happen? >> >> Next - do we have any big brained thinkers who can see specific ways >> we can improve interoperation between Java facilities and libraries >> and the Smalltalks? For the next 12 months, we should work on Java >> integration, rather than C++ integration. We should identify the >> three best things for us to do in this regard, and make them polished >> and compelling. Who is in a position to help that happen? >> >> The final way we can take advantage help the maximum number of people >> find their way to us is to present a united community front to the >> outside world. In the same way I am both a European and a Scot, we >> need to be Smalltalkers *and*members of our individual >> Smalltalk-platform communities. >> >> How can we help make that happen? >> >> This is not a silver bullet. It's going to cause a long-term trend in >> events, not a sudden abrupt change. But it will have a real, if >> gradual effect. (assuming that >> >> Equally, it is not something we should ignore. It is something we >> should make use of. We need to put effort into raising our profile >> over the next 6 months. >> >> On 25 November 2015 at 19:51, Casimiro - GMAIL >> <casimiro.barreto(a)gmail.com> wrote: >>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: >>> >>> >>> >>> On 25/11/2015 19:55, Jimmie Houchin wrote: >>> >>> Much truth in what you say. However, what Oracle choose to invest its money, >>> time, personnel resource into Java does affect its present and future. It >>> has a great affect. But it isn't the whole story. Java has enough momentum >>> in what already exists in the language and vm and what has been release >>> under its license, for businesses to keep going for some time with only what >>> currently exists. >>> >>> Cobol is still alive (and well) after > 50 years. >>> You can expect Java programmers to find jobs for many years yet to come >>> :-) >>> >>> nicolas >>> >>> -- >>> Nicolas Anquetil >>> RMod team -- Inria Lille >>> >>> 1st: Java is extremely profitable. Each android phone, each android TV, each >>> android embedded system pays copyrights to Oracle. >>> 2nd: Much of current cloud infrastructure depends on java. >>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will continue >>> to be used by same reasons these languages are used. >>> >>> IMHO, discussing java is not profitable. Better to discuss things to be than >>> talk about things that already happened. >>> >>> casimiro >>> >>> -- >>> The information contained in this message is confidential and intended to >>> the recipients specified in the headers. If you received this message by >>> error, notify the sender immediately. The unauthorized use, disclosure, copy >>> or alteration of this message are strictly forbidden and subjected to civil >>> and criminal sanctions. >>> >>> == >>> >>> This email may be signed using PGP key ID: 0x4134A417 >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > >

Nov. 30, 2015

Re: [Pharo-dev] About the announcements model for SUnit

by EuanM

Sandi Metz on this issue of fear: https://youtu.be/npOGOmkxuio?t=1077 (You might want to back up a little after watching these 15 seconds, to get a some context) On 30 November 2015 at 00:51, EuanM <euanmee(a)gmail.com> wrote: > When Kent Beck was doing Smalltalk consulting, he wouldn't give SUnit > to his client corporation. > > He would get any dev group to write it themselves from the concepts. > > All of which means I don't think we need to be too precious about the > code - we don;t need to fear it :-) > > On 26 November 2015 at 11:13, Max Leske <maxleske(a)gmail.com> wrote: >> Hi NicolÃ¡s, >> >>> On 26 Nov 2015, at 00:43, NicolÃ¡s Papagna Maldonado <nicolas.papagna(a)gmail.com> wrote: >>> >>> Hi everyone! >>> >>> Lately I've been playing with/digging into the announcements model for >>> SUnit, and have a couple of questions about it. >>> >>> I'm trying to understand the model and I am by no means an expert to it. Any >>> pointers/references/feedback is appreciated. >>> >>> 1) As expected TestCaseEnded is notified after a test case is run in >>> TestResult>>#runCase:, but after some tests I've noticed that the >>> announcement (which is created with the TestResult instance as collaborator) >>> is sent before the passing test case is added to the TestResult instance. >>> That means that one gets notified that a test case has been run >>> successfully, but when inspecting the result, that test case won't be there: >>> >>> runCase: aTestCase >>> [ >>> aTestCase announce: TestCaseStarted withResult: self. >>> aTestCase runCase. >>> *aTestCase announce: TestCaseEnded withResult: self. >>> self addPass: aTestCase*] >>> on: self class failure , self class skip, self class warning, self class >>> error >>> do: [:ex | ex sunitAnnounce: aTestCase toResult: self] >>> >>> Is this the expected behavior? >> >> No, of course not. But what do you mean by âinspecting the resultâ? The TestResult instance should contain the finished test regardless. Say, you inspect the TestResult before the test has been added, then refreshing the inspector (or opening a new one) should correctly show the test case in the result because it has been added in the mean time. >> >> I guess that switching those two statements wouldnât hurt though. >> >>> >>> 2) When a test case does not pass (for whatever reason), the failure is >>> handled and the TestResult instance is updated, but a TestCaseEnded >>> announcement is not sent. So there's a chance that you'd get a >>> TestCaseStarted announcement, but never receive a TestCaseEnded announcement >>> if it didn't pass: >>> >>> runCase: aTestCase >>> [ >>> *aTestCase announce: TestCaseStarted withResult: self.* >>> aTestCase runCase. >>> aTestCase announce: TestCaseEnded withResult: self. >>> self addPass: aTestCase] >>> on: self class failure , self class skip, self class warning, self class >>> error >>> do: [:ex | *ex sunitAnnounce: aTestCase toResult: self*] >>> >>> Is this the expected behavior? >> >> I agree. TestCaseEnded should be announced in all cases. >> >>> >>> 3) When a TestSuiteEnded is announced (TestResult>>#updateResultsInHistory), >>> the announcement instance is created passing in the TestCase subclass as >>> result. So, when sending #testResult to the annoucement, one does not get a >>> TestResult instance (as expected) but the TestCase subclass. >>> >>> updateResultsInHistory >>> |classesToNotify| >>> classesToNotify:= Set new. >>> #(#passed #failures #errors) do: [ :status | >>> (self perform: status) do: [ :testCase | >>> classesToNotify add:testCase class. >>> self class updateTestHistoryFor: testCase status: status ] ]. >>> *classesToNotify do:[:cl | * >>> cl historyAnnouncer announce: (*TestSuiteEnded result: cl*)] >> >> That should probably be âTestSuiteEnded testCase: clâ. If you look at the subscribers to TestSuiteEnded youâll see that #result is used to retrieve the test case. So those senders would need to be updated. but yes, since there is a #testCase: selector itâs pretty bad that the selector used is #result:. >> >>> >>> 4) I've read an old post about using a Dictionary instead of storing the >>> TestResult instance as history, and it seemed like that was the intended >>> design. The only issue I see there is that there could be potentially >>> duplicated code in writing the interpretation of that dictionary (ie. >>> #passed, #failures, #defects, etc..). Has anyone worked with TestCase >>> results history before? if So, which was your approach to do it? >>> >>> Cheers, >>> Nico PM >>> >>> >> >> Thanks for looking at that code! Itâs been lying around for ages and everyone fears it (at least thatâs my impression :) ). >> >> Cheers, >> Max >> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/About-the-announcements-model-for-SUnit-tp4863569.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >>

Nov. 30, 2015

Re: [Pharo-dev] About the announcements model for SUnit

by EuanM

When Kent Beck was doing Smalltalk consulting, he wouldn't give SUnit to his client corporation. He would get any dev group to write it themselves from the concepts. All of which means I don't think we need to be too precious about the code - we don;t need to fear it :-) On 26 November 2015 at 11:13, Max Leske <maxleske(a)gmail.com> wrote: > Hi NicolÃ¡s, > >> On 26 Nov 2015, at 00:43, NicolÃ¡s Papagna Maldonado <nicolas.papagna(a)gmail.com> wrote: >> >> Hi everyone! >> >> Lately I've been playing with/digging into the announcements model for >> SUnit, and have a couple of questions about it. >> >> I'm trying to understand the model and I am by no means an expert to it. Any >> pointers/references/feedback is appreciated. >> >> 1) As expected TestCaseEnded is notified after a test case is run in >> TestResult>>#runCase:, but after some tests I've noticed that the >> announcement (which is created with the TestResult instance as collaborator) >> is sent before the passing test case is added to the TestResult instance. >> That means that one gets notified that a test case has been run >> successfully, but when inspecting the result, that test case won't be there: >> >> runCase: aTestCase >> [ >> aTestCase announce: TestCaseStarted withResult: self. >> aTestCase runCase. >> *aTestCase announce: TestCaseEnded withResult: self. >> self addPass: aTestCase*] >> on: self class failure , self class skip, self class warning, self class >> error >> do: [:ex | ex sunitAnnounce: aTestCase toResult: self] >> >> Is this the expected behavior? > > No, of course not. But what do you mean by âinspecting the resultâ? The TestResult instance should contain the finished test regardless. Say, you inspect the TestResult before the test has been added, then refreshing the inspector (or opening a new one) should correctly show the test case in the result because it has been added in the mean time. > > I guess that switching those two statements wouldnât hurt though. > >> >> 2) When a test case does not pass (for whatever reason), the failure is >> handled and the TestResult instance is updated, but a TestCaseEnded >> announcement is not sent. So there's a chance that you'd get a >> TestCaseStarted announcement, but never receive a TestCaseEnded announcement >> if it didn't pass: >> >> runCase: aTestCase >> [ >> *aTestCase announce: TestCaseStarted withResult: self.* >> aTestCase runCase. >> aTestCase announce: TestCaseEnded withResult: self. >> self addPass: aTestCase] >> on: self class failure , self class skip, self class warning, self class >> error >> do: [:ex | *ex sunitAnnounce: aTestCase toResult: self*] >> >> Is this the expected behavior? > > I agree. TestCaseEnded should be announced in all cases. > >> >> 3) When a TestSuiteEnded is announced (TestResult>>#updateResultsInHistory), >> the announcement instance is created passing in the TestCase subclass as >> result. So, when sending #testResult to the annoucement, one does not get a >> TestResult instance (as expected) but the TestCase subclass. >> >> updateResultsInHistory >> |classesToNotify| >> classesToNotify:= Set new. >> #(#passed #failures #errors) do: [ :status | >> (self perform: status) do: [ :testCase | >> classesToNotify add:testCase class. >> self class updateTestHistoryFor: testCase status: status ] ]. >> *classesToNotify do:[:cl | * >> cl historyAnnouncer announce: (*TestSuiteEnded result: cl*)] > > That should probably be âTestSuiteEnded testCase: clâ. If you look at the subscribers to TestSuiteEnded youâll see that #result is used to retrieve the test case. So those senders would need to be updated. but yes, since there is a #testCase: selector itâs pretty bad that the selector used is #result:. > >> >> 4) I've read an old post about using a Dictionary instead of storing the >> TestResult instance as history, and it seemed like that was the intended >> design. The only issue I see there is that there could be potentially >> duplicated code in writing the interpretation of that dictionary (ie. >> #passed, #failures, #defects, etc..). Has anyone worked with TestCase >> results history before? if So, which was your approach to do it? >> >> Cheers, >> Nico PM >> >> > > Thanks for looking at that code! Itâs been lying around for ages and everyone fears it (at least thatâs my impression :) ). > > Cheers, > Max > >> >> >> >> -- >> View this message in context: http://forum.world.st/About-the-announcements-model-for-SUnit-tp4863569.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

Nov. 30, 2015

Re: [Pharo-dev] Nautilus class definition pane and browseAllAccessesTo

by Nicolai Hess

2015-11-30 0:07 GMT+01:00 Henrik Nergaard <henrin10(a)student.uia.no>: > For the Rubric keybinding; changing the calls using âself modelâ in > RubSmalltalkEditor>>#modelCurrentSelectedClass to call âself model > interactionModelâ instead should make the keybinding work again (at least > changing the one to #selectedBehaviour). > Yes! But I must admit that I don't understand the purpose of the interactionModel, why does the text model has an interaction model ? Do all text model provide it ? > > > Best regards, > > Henrik > > > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Nicolai Hess > *Sent:* Sunday, November 29, 2015 10:32 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] Nautilus class definition pane and > browseAllAccessesTo > > > > In Nautilus class definition pane, if it shows a class definition like > > Object subclass: #RBNamespace > instanceVariableNames: 'changes environment newClasses removedClasses > changedClasses rootClasses implementorsCache sendersCache' > classVariableNames: '' > package: 'Refactoring-Core-Model' > > you can select an inst var and > > use cmd+shift+n to browse all accesses to this var. > > > > I broke this behavior. ( But I find it useful and a I want it back). > > The problem, Rubric needs to know the current selected class (it calls > classOrMetaclass on the > > *interaction model* (Nautilus) to find the class it searches for this inst > var. > > But the same method #classOrMetaclass is called by NEC, and if NEC finds a > class > > it trys to parse the current text as a method definition, but this panes > contains a > > class definition, not a method definition, and this yields to the strange > completions > > (case 16712) this is what I tried to fix when I broke this > browseAllAccessesTo behavior. > > Any Idea how we can get both ? > > - Rubric to find the correct class for browsing inst var access > > - NEC to find *no class* so it does not try to complete the inst var names. > > I don't know how to solve this, I don't understand how rubric delegates > this > > calls (it should be possible to call #selectedBehavior or #selectedClass > but it > > uses some delegates > > rub editing -> rub editor -> rub scrolled text model -> interaction model > -> nautilus ui > > >

Nov. 29, 2015

Re: [Pharo-dev] Nautilus class definition pane and browseAllAccessesTo

by Henrik Nergaard

For the Rubric keybinding; changing the calls using âself modelâ in RubSmalltalkEditor>>#modelCurrentSelectedClass to call âself model interactionModelâ instead should make the keybinding work again (at least changing the one to #selectedBehaviour). Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Sunday, November 29, 2015 10:32 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Nautilus class definition pane and browseAllAccessesTo In Nautilus class definition pane, if it shows a class definition like Object subclass: #RBNamespace instanceVariableNames: 'changes environment newClasses removedClasses changedClasses rootClasses implementorsCache sendersCache' classVariableNames: '' package: 'Refactoring-Core-Model' you can select an inst var and use cmd+shift+n to browse all accesses to this var. I broke this behavior. ( But I find it useful and a I want it back). The problem, Rubric needs to know the current selected class (it calls classOrMetaclass on the *interaction model* (Nautilus) to find the class it searches for this inst var. But the same method #classOrMetaclass is called by NEC, and if NEC finds a class it trys to parse the current text as a method definition, but this panes contains a class definition, not a method definition, and this yields to the strange completions (case 16712) this is what I tried to fix when I broke this browseAllAccessesTo behavior. Any Idea how we can get both ? - Rubric to find the correct class for browsing inst var access - NEC to find *no class* so it does not try to complete the inst var names. I don't know how to solve this, I don't understand how rubric delegates this calls (it should be possible to call #selectedBehavior or #selectedClass but it uses some delegates rub editing -> rub editor -> rub scrolled text model -> interaction model -> nautilus ui

Nov. 29, 2015