- Pharo-users - lists.pharo.org

Re: [Pharo-users] Travis build failing because of bad CRC

by Christophe Demarey

Hi Norbert, > Le 23 nov. 2017 Ã 14:49, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : > > If you are not confident about the diagnosis that's fine. But then it would be cool to come up with a better one Sorry but I do not have a better diagnostic than yours today. > and not giving that "works for me Â». This sentence was just there to add the fact that it is not broken for all people / location. It adds information to help debugging. It does not mean that, because it works for us, we do not investigate or try to find a solution. Yesterday, I set up a new file server at Inria to replace files.pharo.org (at least to test if it is better) but Iâm still waiting that the network unit open the port 80 to the world â¦ Today, I will probably set up a server outside Inria if I have the agreement to do it. > That is not an explanation. Because your assumption would be that externally and internally you use the same system and transport ways. And that is most likely not true. > Just try to find an explanation. Here we go: > > - If I download a zip file from files.pharo.org <http://files.pharo.org/> I open a TCP connection from my laptop to files.pharo.org <http://files.pharo.org/> > - TCP has a checksum in the header that is used to check the integrity of each transferred package > - So I can assume that this packet of the one connection was not tampered > - If it counts for a single packet it counts for the whole file > - With all my assumption I can state that I get exactly what the files.pharo.org <http://files.pharo.org/> is sending me Agree > So what are the possibilities it fails? > > - Either the stack beneath hands out the data to the TCP stack delivers corrupt data. That could be the filesystem hence my thought > - Or there is no single connection between my laptop and files.pharo.org <http://files.pharo.org/>. In that case the data would flow over a proxy. But even if I have two connections and for each the integrity check counts then what I said for one connection counts for two and more as well > - If we really decline beliving the filesystem fails (that is less likely if it works inside of inria) > - Is there anything left? Yes, if the proxy modifies the data you can have data integrity on the first connection, then a program that deliberately changes the content and transfers that integer again over the second connection. So it can be broken on the other end. > > If we then look at the file we might recognize that it has the ending .zip and this is the file type that transfers most viruses over the net. So we even can imagine what kind of proxy that might be, let's call it a virus checker. That is what I would do in order to narrow the problem. Thanks for trying to investigate. At Inria, we have indeed some boxes dedicated to filter network traffic and eliminate spam, viruses. Iâm not sure it is used for the outgoing traffic but it is a potential source of problem. I will check with network unit. By the way, is there a way to have reproducible bad CRC? Christophe

Nov. 24, 2017

PetitCompiler loading problem

by Julien

Hello, Iâd like to try PetitCompiler to speed-up a parser I did. When trying to load it in a Pharo 6.1 image I have an error related to its configuration: Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitCompiler; load. (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadStable'. Â« Error : Name not found : Magritte-Tests-Pharo-Model Â» Can someone help me? I haven't tried in older images. Julien

Nov. 24, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Richard Sargent

Ben, I think you understand the dilemma. My philosophy is to avoid claims that are known to be not provably true. i.e. don't colour it green, because the test runner cannot claim that knowledge. I am agnostic to whether it should be left uncoloured or coloured red to document the fact that it failed (as in was unable to run to completion without a problem). I truly don't care. Our profession has a tendency to make claims which aren't provably true. It is one of the many reasons we have poor software. So I am adamant about avoiding that particular mistake. And, I am adamant about dissuading others from the same kinds of mistakes. Write software which conveys exactly what it can claim without Deus ex machina intervention. The test failed. It was unable to run to completion without an error. It doesn't matter whether that particular error was corrected or not. The software running the test is incapable of determining whether the change that allowed the test to run to completion was code, data editing, or something else and it is incapable of knowing whether whatever allowed the test to finish is a correct fix for the error. Be adamant about what your software can know to be true. Equally important, be adamant about your own approach to problems and solutions. Godel had some good advice. On Nov 23, 2017 19:31, "Ben Coman" <btc(a)openinworld.com> wrote: > > > On 16 November 2017 at 00:20, Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > >> I think that setting the button back to gray is a good behaviour. >>> - it is the same thing that happens once you modify a method (which is >>> what is happening during debugging) >>> - it explicitly says "please rerun the test because you may have >>> introduced side effects" >>> >> >> I would go a little further. Any method modified by the developer during >> the course of running a test voids the ability to claim the test succeeded. >> Likewise, for any object editted in an inspector.ere >> > > So to summarise the viewpoints as I understand them, consider an > interrupted test that later runs to completion > and is then... > > A. incorrectly marked red (or grey) [false negative] > ==> frequent during TDD > ==> need to manually rerun test *every* time > ==> large extra effort for developer > > B. incorrectly marked green [false positive] > ==> infrequent (presumed) > ==> error picked up anytime test is run again, or when test group is run > ==> small extra effort for developer > ==> developer may be aware when they make suspect changes which undermine > test result, to judge to run it again. > > C. test is automatically rerun a second time > ==> infrequently some tests run too long for this to be practical > > A and B are like the philosophical difference between engineers and > scientists. i.e. engineers deal with approximations** that make the design > process more efficient. > For C, I still don't fully understand the concrete problem. How much time > do such tests take? > > Anyway, I prefer early efficiency with late bound correctness, so my vote > would be to avoid A. > > > In other words, if the test run was interrupted, it cannot be considered >> successful. Keep things simple. (as simple as possible) >> > > There are costs associated with perfect correctness. i.e. costs > associated with both false-negatives and false-positives. > The alternate approach is to consider the consequence of temporary > false-positive. > I'd vote for making things as simple and *efficient* as possible. > > cheers -ben > > > **A mathematician, a scientist, and an engineer are given the task of > finding how high a particular red rubber ball will bounce when dropped from > a given height onto a given surface. > The mathematician derives the elasticity of the ball from its chemical > makeup, derives the equations to determine how high it will bounce and > calculates it. > The physicist takes the ball into the lab, measures its elasticity, and > plugs the variables into a formula. > The engineer looks it up in his red rubber ball book. > > > > >> >> >> On Wed, Nov 15, 2017 at 2:49 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> >>> >>> On Wed, Nov 15, 2017 at 11:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com >>> > wrote: >>> >>>> >>>> 2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>> : >>>>> >>>>> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito < >>>>>> guillermopolito(a)gmail.com>: >>>>>> >>>>>>> And just putting it back to gray? As "not run"? >>>>>>> >>>>>> >>>>>> We can implement any logic. >>>>>> Personally I need current behaviour. >>>>>> >>>>> >>>>> But it is not about you personally. It is about implementing the most >>>>> common and the less strange for newcomers. >>>>> >>>> >>>> To know what is the most common case people should tell personal >>>> opinion. >>>> And in this thread only Richard was against current logic. >>>> >>> >>> But you're assuming here that: >>> - people that is not reading this email do not care and don't have a say >>> - so pleople that is not subscribed to the mailing list don't care >>> - and that includes newbies >>> >>> Our role of experienced guys it not only look after "our" best defaults. >>> But also after the defaults of people without experience. >>> >>> I think that setting the button back to gray is a good behaviour. >>> - it is the same thing that happens once you modify a method (which is >>> what is happening during debugging) >>> - it explicitly says "please rerun the test because you may have >>> introduced side effects" >>> >>> Unless you make the debugger more intelligent, you cannot be sure that >>> the result you obtained at the end of the test is really reproducible. And >>> moreover, to be able to make such assumption you should be an expert that >>> understands how the underlying framework behaves. >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov < >>>>>>> dionisiydk(a)gmail.com> wrote: >>>>>>> >>>>>>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>>> >>>>>>>>> Ben Coman wrote >>>>>>>>> > Or it could go to Amber, half-way between green & red to mean >>>>>>>>> probably >>>>>>>>> > correct. >>>>>>>>> >>>>>>>>> Ha ha. >>>>>>>>> >>>>>>>>> Again, it seems that just automatically rerunning the test >>>>>>>>> immediately after >>>>>>>>> a human-manipulated run and setting the color based on that second >>>>>>>>> run >>>>>>>>> addresses all points on both sides, no? >>>>>>>>> >>>>>>>> >>>>>>>> Except that sometimes we are debugging slow test and running it >>>>>>>> second time automatically after "proceed" can be not appropriate. >>>>>>>> We are talking about single test run. If user have any doubts about >>>>>>>> result It is his responsibility to rerun the test. User knows what he is >>>>>>>> doing when he debug and fix the test. No intelligence is required here. >>>>>>>> >>>>>>>> And anyway current fix just provides consistent behaviour to >>>>>>>> debugging from explicit breakpoint/halt. In that case the result was always >>>>>>>> in sync with debug session. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> Cheers, >>>>>>>>> Sean >>>>>>>>> -- >>>>>>>>> Sent from: http://forum.world.st/Pharo-Sm >>>>>>>>> alltalk-Users-f1310670.html >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> Guille Polito >>>>>>> >>>>>>> Research Engineer >>>>>>> >>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>> >>>>>>> CRIStAL - UMR 9189 >>>>>>> >>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>>> <http://www.cnrs.fr>* >>>>>>> >>>>>>> >>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>> >>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> >>>>> CRIStAL - UMR 9189 >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>> <http://www.cnrs.fr>* >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> >

Nov. 24, 2017

Re: [Pharo-users] I love the launcher!!!!

by Ben Coman

Every time I investigate an issue from the tracker, I start with a new fresh image. Often its useful to track down which build introduced a bug, so I need to bisect the last 500 builds or so. I select a build version from the "Template" side and create an image named "CaseCCCCC-BBBBB" where CCCCC is the issue number and BBBBB is the build number. I'll quickly end up with a dozen images then delete all but the two either side of where the bug was introduced, to examine the differences between them, and develop a fix for the later build, then testing that fix in the latest build. Also when someone announces a new library, I can quickly create a new image "SomeProject-BBBBB" which I can dip my toes into as I get time available. Nowadays the matching VM is automatically downloaded, which makes it easier to keep up with the latest VM+Image. cheers -ben On 23 November 2017 at 19:56, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: > >> Hi >> >> I love the PharoLauncher. >> > > Pardon my question, I have downloaded it and looked at it, but I don't get > it. What does it do / what are the use cases (honest question)? > > Thanks, Herby > > > It helps me to manage my parallel development and projects. >> >> We should put a link on the Pharo web site because >> >> http://files.pharo.org/platform/launcher/ >> >> is arcane. >> >> Stef >> >> > >

Nov. 24, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Ben Coman

On 16 November 2017 at 00:20, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > I think that setting the button back to gray is a good behaviour. >> - it is the same thing that happens once you modify a method (which is >> what is happening during debugging) >> - it explicitly says "please rerun the test because you may have >> introduced side effects" >> > > I would go a little further. Any method modified by the developer during > the course of running a test voids the ability to claim the test succeeded. > Likewise, for any object editted in an inspector.ere > So to summarise the viewpoints as I understand them, consider an interrupted test that later runs to completion and is then... A. incorrectly marked red (or grey) [false negative] ==> frequent during TDD ==> need to manually rerun test *every* time ==> large extra effort for developer B. incorrectly marked green [false positive] ==> infrequent (presumed) ==> error picked up anytime test is run again, or when test group is run ==> small extra effort for developer ==> developer may be aware when they make suspect changes which undermine test result, to judge to run it again. C. test is automatically rerun a second time ==> infrequently some tests run too long for this to be practical A and B are like the philosophical difference between engineers and scientists. i.e. engineers deal with approximations** that make the design process more efficient. For C, I still don't fully understand the concrete problem. How much time do such tests take? Anyway, I prefer early efficiency with late bound correctness, so my vote would be to avoid A. In other words, if the test run was interrupted, it cannot be considered > successful. Keep things simple. (as simple as possible) > There are costs associated with perfect correctness. i.e. costs associated with both false-negatives and false-positives. The alternate approach is to consider the consequence of temporary false-positive. I'd vote for making things as simple and *efficient* as possible. cheers -ben **A mathematician, a scientist, and an engineer are given the task of finding how high a particular red rubber ball will bounce when dropped from a given height onto a given surface. The mathematician derives the elasticity of the ball from its chemical makeup, derives the equations to determine how high it will bounce and calculates it. The physicist takes the ball into the lab, measures its elasticity, and plugs the variables into a formula. The engineer looks it up in his red rubber ball book. > > > On Wed, Nov 15, 2017 at 2:49 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Wed, Nov 15, 2017 at 11:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov < >>>> dionisiydk(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com >>>>> >: >>>>> >>>>>> And just putting it back to gray? As "not run"? >>>>>> >>>>> >>>>> We can implement any logic. >>>>> Personally I need current behaviour. >>>>> >>>> >>>> But it is not about you personally. It is about implementing the most >>>> common and the less strange for newcomers. >>>> >>> >>> To know what is the most common case people should tell personal opinion. >>> And in this thread only Richard was against current logic. >>> >> >> But you're assuming here that: >> - people that is not reading this email do not care and don't have a say >> - so pleople that is not subscribed to the mailing list don't care >> - and that includes newbies >> >> Our role of experienced guys it not only look after "our" best defaults. >> But also after the defaults of people without experience. >> >> I think that setting the button back to gray is a good behaviour. >> - it is the same thing that happens once you modify a method (which is >> what is happening during debugging) >> - it explicitly says "please rerun the test because you may have >> introduced side effects" >> >> Unless you make the debugger more intelligent, you cannot be sure that >> the result you obtained at the end of the test is really reproducible. And >> moreover, to be able to make such assumption you should be an expert that >> understands how the underlying framework behaves. >> >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov < >>>>>> dionisiydk(a)gmail.com> wrote: >>>>>> >>>>>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>> >>>>>>>> Ben Coman wrote >>>>>>>> > Or it could go to Amber, half-way between green & red to mean >>>>>>>> probably >>>>>>>> > correct. >>>>>>>> >>>>>>>> Ha ha. >>>>>>>> >>>>>>>> Again, it seems that just automatically rerunning the test >>>>>>>> immediately after >>>>>>>> a human-manipulated run and setting the color based on that second >>>>>>>> run >>>>>>>> addresses all points on both sides, no? >>>>>>>> >>>>>>> >>>>>>> Except that sometimes we are debugging slow test and running it >>>>>>> second time automatically after "proceed" can be not appropriate. >>>>>>> We are talking about single test run. If user have any doubts about >>>>>>> result It is his responsibility to rerun the test. User knows what he is >>>>>>> doing when he debug and fix the test. No intelligence is required here. >>>>>>> >>>>>>> And anyway current fix just provides consistent behaviour to >>>>>>> debugging from explicit breakpoint/halt. In that case the result was always >>>>>>> in sync with debug session. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- >>>>>>>> Cheers, >>>>>>>> Sean >>>>>>>> -- >>>>>>>> Sent from: http://forum.world.st/Pharo-Sm >>>>>>>> alltalk-Users-f1310670.html >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>> >>>>>> CRIStAL - UMR 9189 >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>> <http://www.cnrs.fr>* >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > >

Nov. 24, 2017

Re: [Pharo-users] Travis build failing because of bad CRC

by Ben Coman

On 23 November 2017 at 20:18, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > > > Le 23 nov. 2017 Ã 12:34, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : > > > > > > > >> Am 23.11.2017 um 11:39 schrieb Christophe Demarey < > christophe.demarey(a)inria.fr>: > >> > >> Hi Norbert, > >> > >> I understand your point of view that others probably share. > >> I also agree the situation is very bad: Inria took too much time to > investigate the problem and now, renater also â¦ > >> The question is: would it be really better outside Inria? Maybe ... > maybe not â¦ > > > > Maybe that is the point. It is not a question if it works better outside > because it will. The problem we have is so serious that it will be hard to > find elsewhere. I can only repeat: It is not the download that fails which > TCP wise means that exactly the thing is downloaded that inria offered. So > something below the web server is broken and most probably they have a > corrupt storage solution meaning only if you give it broken to the web > server the broken thing can be transported in a sane manner. > > Iâm not confident with the diagnostic. > I never encountered this problem The problem seems geo-specific. So you may never personally observe the problem. Of course that can make it near-impossible for yourself to troubleshoot. So consider the engineering principal... "If you can't solve the problem, change the problem." cheers -ben

Nov. 24, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Stephane Ducasse

BTW I like grey for a method that was edited in the debugger. Because red is not good. The proof is that when I rerun my test is green. While saying I do not know you have to rerun is a good solution. I like it. I got always frustrated with the red. On Fri, Nov 24, 2017 at 12:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi andrew > > I like your idea. > It is fun and at least we can spot test. > Now sometimes we will have to have self assert: true because running a > code can be also considered as a test. > Now what I do not like is empty test method because there are green. > > stef > > On Tue, Nov 21, 2017 at 10:07 PM, Prof. Andrew P. Black > <black(a)cs.pdx.edu> wrote: >> While we are discussing colors, what should we do about a test that does not make any assertions at all? >> >> A couple of years ago, a smart student who was working on a testing dialect for me decided that such tests should be in a new category all of their own. Later I simplified things and just made these tests fail. I am pretty convinced now that this is the right behaviour. It certainly suits my purposes (teaching TDD); if the student omits to make any assertions, they have a failing test. The message is: "Failure: test made no assertions". >> >> Currently, such a test is green in Pharo. In 2013, I filed a bug report on a bunch of tests of #printOn: on collections that made no assertions. (The test writer didnât understand how streams worked, and made assertions for each element of the empty string.) I was reminded of this just this week, because those tests have yet to be fixed. I suspect that if they had been yellow, rather than green, then they would have been fixed before now. >> >> I plan to fix those tests on Friday, but I also wonder about changing the behaviour of the testing framework. What do you think? >> >> Andrew >> >>

Nov. 23, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Stephane Ducasse

Hi andrew I like your idea. It is fun and at least we can spot test. Now sometimes we will have to have self assert: true because running a code can be also considered as a test. Now what I do not like is empty test method because there are green. stef On Tue, Nov 21, 2017 at 10:07 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: > While we are discussing colors, what should we do about a test that does not make any assertions at all? > > A couple of years ago, a smart student who was working on a testing dialect for me decided that such tests should be in a new category all of their own. Later I simplified things and just made these tests fail. I am pretty convinced now that this is the right behaviour. It certainly suits my purposes (teaching TDD); if the student omits to make any assertions, they have a failing test. The message is: "Failure: test made no assertions". > > Currently, such a test is green in Pharo. In 2013, I filed a bug report on a bunch of tests of #printOn: on collections that made no assertions. (The test writer didnât understand how streams worked, and made assertions for each element of the empty string.) I was reminded of this just this week, because those tests have yet to be fixed. I suspect that if they had been yellow, rather than green, then they would have been fixed before now. > > I plan to fix those tests on Friday, but I also wonder about changing the behaviour of the testing framework. What do you think? > > Andrew > >

Nov. 23, 2017

Re: [Pharo-users] I love the launcher!!!!

by Stephane Ducasse

I select the pharo image I want either from jenkins or from the file server and I click and it selects the correct vm download it and then I can keep the 1000 images I have ordered and in a single user interface and I can manage all my images. To me this is really a pain killer. It makes me super efficient and I like that. Stef On Thu, Nov 23, 2017 at 12:56 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: >> >> Hi >> >> I love the PharoLauncher. > > > Pardon my question, I have downloaded it and looked at it, but I don't get > it. What does it do / what are the use cases (honest question)? > > Thanks, Herby > > >> It helps me to manage my parallel development and projects. >> >> We should put a link on the Pharo web site because >> >> http://files.pharo.org/platform/launcher/ >> >> is arcane. >> >> Stef >> > >

Nov. 23, 2017

Re: [Pharo-users] Travis build failing because of bad CRC

by Stephane Ducasse

I like your analysis and I share your frustration. And this is a so bad press for inria. Stef On Thu, Nov 23, 2017 at 2:49 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 23.11.2017 um 13:18 schrieb Christophe Demarey > <Christophe.Demarey(a)inria.fr>: > > > Le 23 nov. 2017 Ã 12:34, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : > > > > Am 23.11.2017 um 11:39 schrieb Christophe Demarey > <christophe.demarey(a)inria.fr>: > > Hi Norbert, > > I understand your point of view that others probably share. > I also agree the situation is very bad: Inria took too much time to > investigate the problem and now, renater also â¦ > The question is: would it be really better outside Inria? Maybe ... maybe > not â¦ > > > Maybe that is the point. It is not a question if it works better outside > because it will. The problem we have is so serious that it will be hard to > find elsewhere. I can only repeat: It is not the download that fails which > TCP wise means that exactly the thing is downloaded that inria offered. So > something below the web server is broken and most probably they have a > corrupt storage solution meaning only if you give it broken to the web > server the broken thing can be transported in a sane manner. > > > Iâm not confident with the diagnostic. > I never encountered this problem and we got no such feedback from people in > the team. So it is really strange. Indeed, if CRC is worn it does not mean > slowness but corrupted data â¦ I do not see any reason that we do have CRC > from outside Inria but not inside. > If no solution is found today or tomorrow, we will probably see to host a > solution outside Inria. > > > If you are not confident about the diagnosis that's fine. But then it would > be cool to come up with a better one and not giving that "works for me". > That is not an explanation. Because your assumption would be that externally > and internally you use the same system and transport ways. And that is most > likely not true. > Just try to find an explanation. Here we go: > > - If I download a zip file from files.pharo.org I open a TCP connection from > my laptop to files.pharo.org > - TCP has a checksum in the header that is used to check the integrity of > each transferred package > - So I can assume that this packet of the one connection was not tampered > - If it counts for a single packet it counts for the whole file > - With all my assumption I can state that I get exactly what the > files.pharo.org is sending me > > So what are the possibilities it fails? > > - Either the stack beneath hands out the data to the TCP stack delivers > corrupt data. That could be the filesystem hence my thought > - Or there is no single connection between my laptop and files.pharo.org. In > that case the data would flow over a proxy. But even if I have two > connections and for each the integrity check counts then what I said for one > connection counts for two and more as well > - If we really decline beliving the filesystem fails (that is less likely if > it works inside of inria) > - Is there anything left? Yes, if the proxy modifies the data you can have > data integrity on the first connection, then a program that deliberately > changes the content and transfers that integer again over the second > connection. So it can be broken on the other end. > > If we then look at the file we might recognize that it has the ending .zip > and this is the file type that transfers most viruses over the net. So we > even can imagine what kind of proxy that might be, let's call it a virus > checker. That is what I would do in order to narrow the problem. > > Norbert >

Nov. 23, 2017