- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #171: 20309 - Startup should run always in a fresh process

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #171 was: SUCCESS. The Pull Request #198 was integrated: "20309 - Startup should run always in a fresh process" Pull request url: https://github.com/pharo-project/pharo/pull/198 Issue Url: https://pharo.fogbugz.com/f/cases/20309 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017

Re: [Pharo-dev] State of files.pharo.org

by Christophe Demarey

Hello, I just finished the meeting with a guy from Inria datacenter. >From Inria, we do not see any problem with files.pharo.org. We do not have tools ready to simulate poor networks nor remote network sensors available :( Thatâs why if some of you could help to collect some data to guess what is the problem, it would be great: If you can run the commands listed there: https://pad.inria.fr/p/IvdGLh650VN8lkoN and also put the results at the bottom of the page, it would be very helpful. In the same time, I created a project on github to run these command on travis CI: https://travis-ci.org/demarey/test-files-pharo-org. With all this data, I hope they can spot the problem quickly. Thanks, Christophe

Oct. 6, 2017

Re: [Pharo-dev] State of files.pharo.org

by Ben Coman

Often the problem is not that they cannot find a reason why, but before that, they cannot even see it, i.e. they can't put the hands around it. Its human nature that we deal with the world through our own experiences. If a problem can't be seen, how can it be solved. Without know what actions they may have tries, I'd generally say it seems that it can't be solved with local testing since that is a different environment. Ideally your DevOps guys could get on a machine in a remote corner of the world exhibiting the problem, to help them "see" the problem. That said, right now for me from different location its not too bad. Perhaps it only get in a twist with lagged/dropped packets on poor networks. Do they test using tools to simulate poor networks? * https://stackoverflow.com/questions/130354/how-do-i-simulate-a-low-bandwidt… * https://www.hanselman.com/blog/HowToSimulateALowBandwidthConnectionForTesti… cheers -ben On Fri, Oct 6, 2017 at 4:12 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > We have to circumvent the DevOp mental model :) From their point of view > it goes like this > > "I cannot find a reason why it shouldn't workâ¦.so it should. Ticket > closed!" > > Just ignoring the little effect THAT.IT.DOES.NOT.WORK > > Same story everywhere :) > > Norbert > > > Am 06.10.2017 um 10:01 schrieb Stephane Ducasse <stepharo.self(a)gmail.com > >: > > > > Thanks Christophe because Peter reported the same when I visiting him > > and this is slowly killing us. > > > > On Thu, Oct 5, 2017 at 2:18 PM, Christophe Demarey > > <christophe.demarey(a)inria.fr> wrote: > >> > >> Le 5 oct. 2017 Ã 13:50, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit > : > >> > >> > >> > >> On 5 Oct 2017, at 13:35, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> I'm trying to download images from files.pharo.org. Either it takes a > lot of > >> time or get something like > >> > >> Downloading the latest 70 Image: > >> http://files.pharo.org/get-files/70/pharo.zip > >> error: invalid compressed data to inflate > >> image.7vLfZK/Pharo7.0-32bit-6bff78c.image > >> image.7vLfZK/Pharo7.0-32bit-6bff78c.sources bad CRC 724d27ab (should > be > >> f4d1baa8) > >> > >> That is really sad. What use is this wonderful environment if nobody can > >> download it? We need to sort that out. > >> > >> So is this hosted in Inria data center? > >> > >> > >> Yes, and the admins can not find any problem. They closed the ticket I > >> opened, but there is a new > >> ticket open since last weekâ¦ not a good situation. > >> > >> > >> Yes, it is hosted at Inria datacenter. > >> They are investigating the problem. I have an audio conf with them > tomorrow > >> on this pb. I will give a feedback after this meeting. > >> > >> Christophe > >> > >> > >

Oct. 6, 2017

[Ann] PharoLauncher v1.0.1 released!

by Christophe Demarey

Hi all, I just released a new version of the PharoLauncher 1.0.1. Here are major improvements since last version: Pharo launcher is now distributed with a Pharo 60 image with a 32-bits threaded VM (to avoid hangs when using OSProcess). Add a VM management utility able to find (and download) the appropriate VM for a given image. So, the launcher is NOT shipped anymore with an extra VM. It will fetch required VM when needed. Pharo Launcher files (images, VMs) are now considered as user Documents (easier to find). Consequently, they are now stored in the standard documents folder, i.e. $HOME/Documents/Pharo on OS X, $HOME/My Documents/Pharo on windows, $HOME/Pharo on Linux (some linux distributions provide a document folder but some others not, so we put it in the HOME directory in all cases). In this folder, you will find your images and virtual machines needed to run images. Use of ProcessWrapper to run images on Windows. Adds download of sources file for Pharo images > 60. Left panel is now used for official images and Jenkins jobs templates and right panel is used for local images. New mooc entry with the image ready to start the Pharo Mooc. New deprecated category to find old official Pharo images. Use system unzip when possible (Pharo unzip does not manage file permissions nor symbolic links). You can get platform bundles from files.pharo.org: Os X: http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg Windows: http://files.pharo.org/platform/launcher/pharo_installer-1.0.1.exe Linux: http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip Enjoy, Christophe. For those wanted more info on how the adequate VM is computed, here is the process: determine the image format version find (and optionnaly fetch) a compatible VM (a VM able to run this image format) and run the image to get its Pharo version number find (and optionnaly fetch) the appropriate VM for this specific Pharo image version. Sources files are also downloaded with the VM when applicable. run the image with the appropriate VM

Oct. 6, 2017

[Pharo 7.0-dev] Build #169: 20491-Epica-recovery-dialog-always-on-the-image-start-up

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #169 was: SUCCESS. The Pull Request #331 was integrated: "20491-Epica-recovery-dialog-always-on-the-image-start-up" Pull request url: https://github.com/pharo-project/pharo/pull/331 Issue Url: https://pharo.fogbugz.com/f/cases/20491 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017

[Pharo 7.0-dev] Build #170: 20480-Runable-Example-label-is-mis-spelled

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #170 was: SUCCESS. The Pull Request #333 was integrated: "20480-Runable-Example-label-is-mis-spelled" Pull request url: https://github.com/pharo-project/pharo/pull/333 Issue Url: https://pharo.fogbugz.com/f/cases/20480 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017

Re: [Pharo-dev] State of files.pharo.org

by Norbert Hartl

We have to circumvent the DevOp mental model :) From their point of view it goes like this "I cannot find a reason why it shouldn't workâ¦.so it should. Ticket closed!" Just ignoring the little effect THAT.IT.DOES.NOT.WORK Same story everywhere :) Norbert > Am 06.10.2017 um 10:01 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Thanks Christophe because Peter reported the same when I visiting him > and this is slowly killing us. > > On Thu, Oct 5, 2017 at 2:18 PM, Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: >> >> Le 5 oct. 2017 Ã 13:50, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : >> >> >> >> On 5 Oct 2017, at 13:35, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> I'm trying to download images from files.pharo.org. Either it takes a lot of >> time or get something like >> >> Downloading the latest 70 Image: >> http://files.pharo.org/get-files/70/pharo.zip >> error: invalid compressed data to inflate >> image.7vLfZK/Pharo7.0-32bit-6bff78c.image >> image.7vLfZK/Pharo7.0-32bit-6bff78c.sources bad CRC 724d27ab (should be >> f4d1baa8) >> >> That is really sad. What use is this wonderful environment if nobody can >> download it? We need to sort that out. >> >> So is this hosted in Inria data center? >> >> >> Yes, and the admins can not find any problem. They closed the ticket I >> opened, but there is a new >> ticket open since last weekâ¦ not a good situation. >> >> >> Yes, it is hosted at Inria datacenter. >> They are investigating the problem. I have an audio conf with them tomorrow >> on this pb. I will give a feedback after this meeting. >> >> Christophe >> >>

Oct. 6, 2017

Re: [Pharo-dev] State of files.pharo.org

by Stephane Ducasse

Thanks Christophe because Peter reported the same when I visiting him and this is slowly killing us. On Thu, Oct 5, 2017 at 2:18 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Le 5 oct. 2017 Ã 13:50, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > > > On 5 Oct 2017, at 13:35, Norbert Hartl <norbert(a)hartl.name> wrote: > > I'm trying to download images from files.pharo.org. Either it takes a lot of > time or get something like > > Downloading the latest 70 Image: > http://files.pharo.org/get-files/70/pharo.zip > error: invalid compressed data to inflate > image.7vLfZK/Pharo7.0-32bit-6bff78c.image > image.7vLfZK/Pharo7.0-32bit-6bff78c.sources bad CRC 724d27ab (should be > f4d1baa8) > > That is really sad. What use is this wonderful environment if nobody can > download it? We need to sort that out. > > So is this hosted in Inria data center? > > > Yes, and the admins can not find any problem. They closed the ticket I > opened, but there is a new > ticket open since last weekâ¦ not a good situation. > > > Yes, it is hosted at Inria datacenter. > They are investigating the problem. I have an audio conf with them tomorrow > on this pb. I will give a feedback after this meeting. > > Christophe > >

Oct. 6, 2017

Re: [Pharo-dev] Iceberg - loading baseline

by Jan BlizniÄenko

Actually I found it in Iceberg source code :) Never seen it anywhere else before or after. Jan EstebanLM wrote >> On 4 Oct 2017, at 16:29, Sean P. DeNigris < > sean@ > > wrote: >> >> Jan BlizniÄenko wrote >>> ...'gitlocal:///C:/Users/User/Pharo/repo/nameofmyproject/filetree'; >>> load. >> >> Hmm, I never saw gitlocal:// before. I always use filetree://. I wonder >> what >> the difference isâ¦ > > filetree uses filetree (old way) and it will install the project without > installing an iceberg project. > gitlocal will treat repo as a local repository and it will follow âiceberg > pathâ :) > > Esteban > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 6, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by Sven Van Caekenberghe

> On 6 Oct 2017, at 05:34, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hi Nicolas > > 2017-10-05 16:04 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> >> >> 2017-10-05 15:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >>> >>> I tried, now I get an exception "Use ExternalAddress instead!" >>> >>> I guess the message means Use ExternalAddres in the "out" parameter. >>> But replacing byte with ExternalAddress also crashes the VM (crash.dmp >>> attached). >>> >>> >>> >>> 2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>>> On 5 Oct 2017, at 14:55, HernÃ¡n Morales Durand >>>>> <hernan.morales(a)gmail.com> wrote: >>>>> >>>>> Forgot to comment that Nacl worked in Pharo 5. >>>> >>>> yes but that was with NB and there are some minimum differences. >>>> I do not have the library and I lack the time to try more, but seems to >>>> me that here: >>>> >>>> apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength: >>>> inByteArrayLength >>>> >>>> ^ self >>>> ffiCall: #(long crypto_hash_sha512_ref (byte * >>>> outByteArray, byte * inByteArray, ulonglong * inByteArrayLength)) >>>> module: 'libsodiumâ. >>>> >>>> >>>> instead "byte * outByteArrayâ, you want "byte **outByteArrayâ >>>> >>>> can you try? >>>> >>>> Esteban >>>> >> >> >> Hmm no, internet reference says: >> >> extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char >> *,unsigned long long); >> >> The error is rather that you pass the address of length rather than the >> length... >> So you pass an erroneous length that may lead to a segfault... >> > > Yes, that extra * was the error indeed. > Thank you Nicolas. > > I do not know the VM internals, however I wonder if it is > understandable to expect a VM crash for a typo like this? > Maybe it is too difficult to catch in the VM side? > > Just asking, not criticizing anyone's work. Of course that is normal. This is C code, any error has the potential to crash your program. In C there are no runtime safe guards. There is a reason why we like/use Pharo. > HernÃ¡n > >>>> >>>> >>>>> >>>>> Cheers, >>>>> >>>>> HernÃ¡n >>>>> >>>>> 2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> H Hernani, >>>>>> >>>>>> Most probably is a problem in the library and not UFFI, but I could >>>>>> not know without a crash report. >>>>>> >>>>>> Esteban >>>>>> >>>>>>> On 5 Oct 2017, at 06:00, HernÃ¡n Morales Durand >>>>>>> <hernan.morales(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I ported Nacl (a libsodium wrapper) from the old FFI apicall: format >>>>>>> to use the UFFI ffiCall:, but there should be something terribly >>>>>>> wrong >>>>>>> because is crashing the VM, in both Windows 8.1 and Linux. >>>>>>> >>>>>>> How to reproduce in Pharo 6.1 >>>>>>> >>>>>>> Metacello new >>>>>>> smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; >>>>>>> configuration: 'Nacl'; >>>>>>> version: #development; >>>>>>> load. >>>>>>> >>>>>>> (Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex >>>>>>> >>>>>>> This one does deserve a bug entry? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> HernÃ¡n

Oct. 6, 2017