November 2017 - Pharo-users

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

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

by Cyril Ferlicot

On jeu. 23 nov. 2017 at 23:49, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > This is super strange because I have a quite bad internet connection > at home but I never have such problem just super slow donwload > but this is my connection. > At Synectique we have a connection that can DL at 11Mo/sec on a server, but we regularly get "bad CRC" while using zero conf. Or one execution of zero conf is randomly longer than the others. It does not seems to come from the server/user connection. > Stef > > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 23, 2017

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

by Stephane Ducasse

This is super strange because I have a quite bad internet connection at home but I never have such problem just super slow donwload but this is my connection. Stef On Thu, Nov 23, 2017 at 10:19 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Christophe, > >> Am 23.11.2017 um 09:33 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: >> >> >>> Le 23 nov. 2017 Ã 09:08, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : >>> >>> We need to exit Inria and do our own infrastructure. >> >> Marcus, could you elaborate? Why do we need to exit Inria? >> Do you have money to pay the infrastructure? Inria provides it for free for the Pharo consortium. >> Of course, the problem is super annoying but the problem is not directly related to Inria. It is related to Renater (national research and education network in France), the network Inria is connected to. An incident is open there. I still have no feedback, so cannot say why it takes so much time to solve the problem. > > your view might be too technical here. Aren't you the one that does Cargo so dependencies are well known to you? ;) > The point is that it just does not work and it doesn't matter whose fault this is. The point is that it is there for a long time and nobody way able to fix it. Everyone including you is working so hard on the future for pharo. But this behaviour is like a slap in the face of everyone working for pharo. You drive away newcomers and people that would like to work with pharo. It is not possible to download an image or vm or something from smalltalkhub reliably. > If this is not fully clear let me tell you what I did yesteray. I resurrected an older project and ported it pharo6. In order to download the image I had the execute the curl command 6 times in a row and another two times to get a vm. Then I tried loading the project with metacello and get a debugger because the downloaded archive is corrupt. I need to open the full debugger to see which file it is. Then I need to remove the corrupt file from the package-cache and restart. And yesterdayI had to do this more then 30 (!!!) times until I could load the full project. > > I think it is completely out of question to wait until is able to fix it. And if the money of the consortium is not enough to pay such a service then we need to put in some more. I'm all ears! > > Norbert >

Nov. 23, 2017

Re: [Pharo-users] Short report about Pharo experience

by Stephane Ducasse

You see I documented for example how to use travis and bintray. Super boring to turn a log into a pillar doc. And this way other people can use this doc. Do you know the Soup of Stones (check on wikipedia) ? Stef On Thu, Nov 23, 2017 at 11:40 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi hans > > No need to overreact. > WE VALUE FEEDBACK. > Now if people would understand that yes they can do a simple commit to > recategorise a method. > Then we could also focus on more important things. > > NOW FEEDBACK is great. Then what? > > Stef > > > On Thu, Nov 23, 2017 at 11:53 AM, Hans <hnbeck(a)educational-concepts.biz> wrote: >> Hi Stef, >> >> my post is intended as feedback. Action is a different thing. Feedback may >> help to indentify useful actions. In this sense, I thought feed back is >> help, too. May be I'm wrong. >> >> If you thing feed back is useless and without value, and only "action" >> counts, then is this your opinion. Then I'll take my actions (which are >> there, I develop on TeaPot, as you could read) and be quiet. Full Stop. >> >> Hans >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>

Nov. 23, 2017

Re: [Pharo-users] Short report about Pharo experience

by Stephane Ducasse

Hi hans No need to overreact. WE VALUE FEEDBACK. Now if people would understand that yes they can do a simple commit to recategorise a method. Then we could also focus on more important things. NOW FEEDBACK is great. Then what? Stef On Thu, Nov 23, 2017 at 11:53 AM, Hans <hnbeck(a)educational-concepts.biz> wrote: > Hi Stef, > > my post is intended as feedback. Action is a different thing. Feedback may > help to indentify useful actions. In this sense, I thought feed back is > help, too. May be I'm wrong. > > If you thing feed back is useless and without value, and only "action" > counts, then is this your opinion. Then I'll take my actions (which are > there, I develop on TeaPot, as you could read) and be quiet. Full Stop. > > Hans > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Nov. 23, 2017

Re: [Pharo-users] Short report about Pharo experience

by Richard Sargent

(damned auto-correct! Please ignore the stupid apostrophes in "let's" and "it's" and any other I've missed.) On Nov 23, 2017 10:08, "Richard Sargent" <richard.sargent(a)gemtalksystems.com> wrote: > Dimitris, you have nailed it! > > I've long complained about Smalltalk development tools which prevent one > from easily getting hands on the underlying objects (gui and domain model) > to work directly with them. > > I've long complained about code tools that don't provide the functionality > of the browsers. e.g. a difference tool that only has functionality limited > to showing the differences. > > I've long complained about applications that don't do what I want and > don't provide a powerful scripting language. > > > Based on what you wrote, I would say that there is a reason to present an > application which appears closed, but in reality still let's one get into > the full development environment and work directly with it's underlying > objects. > > So, my ideal application would start with only it's windows / UI, but > which would easily allow me to open inspectors on the GUI instance or it's > domain object and would easily allow me to open the full Smalltalk > environment, too. (And to be able to close it back up to just the > application UI once again.) > > THAT would be a powerful application! > > > > On Nov 22, 2017 23:58, "Dimitris Chloupis" <kilon.alios(a)gmail.com> wrote: > > - Deployment: it should be possible to deploy a âsingle clickâ >> application, independet if native GUI or Web App or Shiny like >> - More standard solutions: many libraries have examples, but they are >> sometimes to trivial or just irrelevant for daily practice >> - More product oriented: libraries should have more wizzards or >> application pattern. Imaginary example: for Teapot or Seaside would it be >> fine if there were some code generator for a 4 Tile dashboard app, or a >> data viz app, themes like in hugo or bootstrap. I may be wrong, but the >> nature of many libraries or tools is âmake anything possibleâ instread of >> âI help you to write your productâ. Do you understand what I want to say ? >> >> Anyway. I can state: Phare IS on the right way. It is. Much much progress >> the last years. Thank you all ! And if it becomes more and more a product >> for professionals (in industry), the future will be top ! And this doesnet >> mean to give up the computer science part. Pharo is cool to try concepts >> and ideas. So Pharo has BOTH sides, which does it make great. >> >> Cheers >> >> Hans >> > > if by single click you mean you press a button and an application is > created , technically with pharo you dont even need to push a button, as > pharo is already an application. > > Pharo is not an IDE, is not a language, is not a virtual os , or a live > coding enviroment. Its simply an application that fullfils all these > roles.You may say "so what, everything is an application" , well not quite > because Pharo is an application practically written in itself offering you > direct access to all its internal making it completely customisable. Even > its VM can be customised from inside Pharo which if you think about it, > other languages would consider this a form of insanity and to a point they > are correct to do so. > > Thus there is no point of creating standalone applications with Pharo > because this goes against its very ideology of IDE, most IDEs nowdays miss > the I, standing for Integration which means that you integrate development > tools, plus language plus your code in one thing. These things are not used > merely to create the application they are meant to be included with the > application you create. I usually say to people that they have no clue what > integration means until they coded in Smalltalk. Smalltalk is just light > years ahead in that departmen and so is Pharo. > > A standalone application rips these things apart , its the seperation > between development builds and release builds that are far less meaningful > for Pharo and you will rarely read about them in this mailing list. > > The actual problem of Pharo is the sever lack of documentation. Its much > better nowdays than it used to but the fact remains that biggest weakness > of Pharo is that it moves about 1000 times faster than its documentation. > This is one huge disadvantage of a very productive/ succesful development > enviroment. > > Python which is a language I also regularly use on daily basise, its a > language that barely changes wtih each version. The only singificant change > for Python was Python 3 and even that pales in comparison to the massive > changes we see in each Pharo version. The next version of Pharo for example > may have a completely new GUI API , that is something you rarely see > happening to a language. This is ok because Pharo obviously is not a > programming language and neither is Smalltalk. > > On the matter of standalone applications , Pharo offers a masive degree of > customisation that is unknown even amongst its most experienced users. > Pretty much anything you see and dont see is customisable. So ironically > Pharo offers a much larger degree of efficiency for generating standalone > applications than any IDE or language out there , or even third party tool. > By standalone in this case I mean application that execute by themselves > without even a need to be installed. > > The reason for this, is the same reason Pharo is so extremely productive. > Its not the live enviroment, its not the pure OOP, its not the IDE, or the > simplicity of the language. > > Its the I, Integration. > > No language or IDE , however much more powerful it may seem can ever come > close to competing with Pharo. That does not make Pharo the best choice, > just the most flexible. > > In the end the fact that Pharo evolution is thousands times faster than > its documentaiton is a very solid reason not to use Pharo and not to > recommend to others. Because in the end documentation is extremely > important. > > But this is one of those scenarios of not having your cake and eating too. > With Pharo you choose to sacrifice documentation for high coding > productivity. Of course lack of documentation hinders productivity but that > is only temporarily until you learn what you want to learn. But then > learning what you want make take years if not decades. > > To explain how one can create a standalone application with Pharo in full > detail is to explain the entire Pharo in full detail. This is why articles > that have been written in the past just barely scratch the surface and tend > to give the opposite impression. > > Bottom line if you come to Pharo for wizards, documentation and generally > hand holding attitude , go back to Python. Python is excellent at this role > and is practically untouchable by its competition which is why it is > considered the king of "ease of use". Pharo is the exact opposite, its > difficult , frustration, annoying, messy and extremely manual. > > But if you search for most the powerful and flexible development > enviroment in the world. Nothing comes remotely close to Pharo. Pharo is > the undisputed king of Integration. It will blow your mind like a nuclear > explosion of how extremely customisable it is. > > Which lead to the inate question what makes one more productive the Python > or the Pharo ideology ? > > My answer is that Python offers more productivity in the short run (which > is why is No 1 if not the only recommended language for beginners to > coding) but in the long run after extensive study of the Pharo enviroment , > which means reading tons upon tons of code (it sucks I know, especially > when you realise that not even classes have comments), Pharo is the clear > winner. As soon as you eliminate the need for documentation and wizard like > attitude Pharo moves at the speed of light. > > There is an effort to make Pharo more Pythonic, but to be sincere, Pharo > will always be Pharo and personally I do not like to hide Pharo shortcoming > as I do not like to to hide its strenghts. > > Pharo essentially does not care about other languages, because its not a > language. > Pharo essentially does not care about IDEs, because its not an IDE. > Pharo essentially does not care about wizards, because its not wzard. > > Pharo's charm is that it has the courage to say "I do not care , I will do > things my way" and just push forward. > > So you could say Pharo is the very definition of acquired taste. Its not > so much about being better and more about being diffirent. Which is a > breath of fresh air in the world that everybody copies everybody else. > > So my advince to all newcomers is that if you are here for the right > reasons and ready to commit to the Pharo ideology, arm yourself with > massive amount of patience and march on. It will be a bumpy but extremely > rewarding ride and completly change the way you think about coding and > especially about OOP. > > >

Nov. 23, 2017

Re: [Pharo-users] Short report about Pharo experience

by Richard Sargent

Dimitris, you have nailed it! I've long complained about Smalltalk development tools which prevent one from easily getting hands on the underlying objects (gui and domain model) to work directly with them. I've long complained about code tools that don't provide the functionality of the browsers. e.g. a difference tool that only has functionality limited to showing the differences. I've long complained about applications that don't do what I want and don't provide a powerful scripting language. Based on what you wrote, I would say that there is a reason to present an application which appears closed, but in reality still let's one get into the full development environment and work directly with it's underlying objects. So, my ideal application would start with only it's windows / UI, but which would easily allow me to open inspectors on the GUI instance or it's domain object and would easily allow me to open the full Smalltalk environment, too. (And to be able to close it back up to just the application UI once again.) THAT would be a powerful application! On Nov 22, 2017 23:58, "Dimitris Chloupis" <kilon.alios(a)gmail.com> wrote: - Deployment: it should be possible to deploy a âsingle clickâ application, > independet if native GUI or Web App or Shiny like > - More standard solutions: many libraries have examples, but they are > sometimes to trivial or just irrelevant for daily practice > - More product oriented: libraries should have more wizzards or > application pattern. Imaginary example: for Teapot or Seaside would it be > fine if there were some code generator for a 4 Tile dashboard app, or a > data viz app, themes like in hugo or bootstrap. I may be wrong, but the > nature of many libraries or tools is âmake anything possibleâ instread of > âI help you to write your productâ. Do you understand what I want to say ? > > Anyway. I can state: Phare IS on the right way. It is. Much much progress > the last years. Thank you all ! And if it becomes more and more a product > for professionals (in industry), the future will be top ! And this doesnet > mean to give up the computer science part. Pharo is cool to try concepts > and ideas. So Pharo has BOTH sides, which does it make great. > > Cheers > > Hans > if by single click you mean you press a button and an application is created , technically with pharo you dont even need to push a button, as pharo is already an application. Pharo is not an IDE, is not a language, is not a virtual os , or a live coding enviroment. Its simply an application that fullfils all these roles.You may say "so what, everything is an application" , well not quite because Pharo is an application practically written in itself offering you direct access to all its internal making it completely customisable. Even its VM can be customised from inside Pharo which if you think about it, other languages would consider this a form of insanity and to a point they are correct to do so. Thus there is no point of creating standalone applications with Pharo because this goes against its very ideology of IDE, most IDEs nowdays miss the I, standing for Integration which means that you integrate development tools, plus language plus your code in one thing. These things are not used merely to create the application they are meant to be included with the application you create. I usually say to people that they have no clue what integration means until they coded in Smalltalk. Smalltalk is just light years ahead in that departmen and so is Pharo. A standalone application rips these things apart , its the seperation between development builds and release builds that are far less meaningful for Pharo and you will rarely read about them in this mailing list. The actual problem of Pharo is the sever lack of documentation. Its much better nowdays than it used to but the fact remains that biggest weakness of Pharo is that it moves about 1000 times faster than its documentation. This is one huge disadvantage of a very productive/ succesful development enviroment. Python which is a language I also regularly use on daily basise, its a language that barely changes wtih each version. The only singificant change for Python was Python 3 and even that pales in comparison to the massive changes we see in each Pharo version. The next version of Pharo for example may have a completely new GUI API , that is something you rarely see happening to a language. This is ok because Pharo obviously is not a programming language and neither is Smalltalk. On the matter of standalone applications , Pharo offers a masive degree of customisation that is unknown even amongst its most experienced users. Pretty much anything you see and dont see is customisable. So ironically Pharo offers a much larger degree of efficiency for generating standalone applications than any IDE or language out there , or even third party tool. By standalone in this case I mean application that execute by themselves without even a need to be installed. The reason for this, is the same reason Pharo is so extremely productive. Its not the live enviroment, its not the pure OOP, its not the IDE, or the simplicity of the language. Its the I, Integration. No language or IDE , however much more powerful it may seem can ever come close to competing with Pharo. That does not make Pharo the best choice, just the most flexible. In the end the fact that Pharo evolution is thousands times faster than its documentaiton is a very solid reason not to use Pharo and not to recommend to others. Because in the end documentation is extremely important. But this is one of those scenarios of not having your cake and eating too. With Pharo you choose to sacrifice documentation for high coding productivity. Of course lack of documentation hinders productivity but that is only temporarily until you learn what you want to learn. But then learning what you want make take years if not decades. To explain how one can create a standalone application with Pharo in full detail is to explain the entire Pharo in full detail. This is why articles that have been written in the past just barely scratch the surface and tend to give the opposite impression. Bottom line if you come to Pharo for wizards, documentation and generally hand holding attitude , go back to Python. Python is excellent at this role and is practically untouchable by its competition which is why it is considered the king of "ease of use". Pharo is the exact opposite, its difficult , frustration, annoying, messy and extremely manual. But if you search for most the powerful and flexible development enviroment in the world. Nothing comes remotely close to Pharo. Pharo is the undisputed king of Integration. It will blow your mind like a nuclear explosion of how extremely customisable it is. Which lead to the inate question what makes one more productive the Python or the Pharo ideology ? My answer is that Python offers more productivity in the short run (which is why is No 1 if not the only recommended language for beginners to coding) but in the long run after extensive study of the Pharo enviroment , which means reading tons upon tons of code (it sucks I know, especially when you realise that not even classes have comments), Pharo is the clear winner. As soon as you eliminate the need for documentation and wizard like attitude Pharo moves at the speed of light. There is an effort to make Pharo more Pythonic, but to be sincere, Pharo will always be Pharo and personally I do not like to hide Pharo shortcoming as I do not like to to hide its strenghts. Pharo essentially does not care about other languages, because its not a language. Pharo essentially does not care about IDEs, because its not an IDE. Pharo essentially does not care about wizards, because its not wzard. Pharo's charm is that it has the courage to say "I do not care , I will do things my way" and just push forward. So you could say Pharo is the very definition of acquired taste. Its not so much about being better and more about being diffirent. Which is a breath of fresh air in the world that everybody copies everybody else. So my advince to all newcomers is that if you are here for the right reasons and ready to commit to the Pharo ideology, arm yourself with massive amount of patience and march on. It will be a bumpy but extremely rewarding ride and completly change the way you think about coding and especially about OOP.

Nov. 23, 2017

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

by Tim Mackinnon

I think the days of running this stuff yourselves are disappearingâ¦ I think many OSS projects rely on SAS for this now - outsource it. We already do Travis - and maybe can leverage that more (but it seems a bit cumbersome) - OR there are fuller service solutions like what AWS does, or GitLab CI - but they will take time to migrate to. Tim > On 23 Nov 2017, at 12: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 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.

Nov. 23, 2017

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

by Norbert Hartl

> 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 <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 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. Norbert

Nov. 23, 2017

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

by Christophe Demarey

> 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.

Nov. 23, 2017