October 2017 - Pharo-dev - lists.pharo.org

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

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

by HernÃ¡n Morales Durand

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

Re: [Pharo-dev] Spec enhancements

by Stephane Ducasse

Thanks good idea. I will have a look On Thu, Oct 5, 2017 at 2:34 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Stephane, > > You may check the SpecUIAddOns > > Metacello new > smalltalkhubUser: 'hernan' project: 'SpecUIAddOns'; > configuration: 'SpecUIAddOns'; > version: #bleedingEdge; > load: 'Core'. > > Most widgets has examples in class side. > > Cheers, > > HernÃ¡n > > > > > 2017-10-05 4:55 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> Hi rob >> >> I like you extensions to label and text. >> I harvested them with the tests and I will slowly generalise that >> to other widgets. >> >> I published my current code experiments to >> >> MCSmalltalkhubRepository >> owner: 'Pharo' >> project: 'Spec' >> user: '' >> password: '' >> >> >> Stef >> >

Oct. 5, 2017

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

by Nicolas Cellier

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... > > > > >> > >> 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. 5, 2017

Re: [Pharo-dev] Non-deterministic ombu errors

by Martin Dias

Ok but for 6.0 there was already https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail-while-reading-non-a… The same test failed and then I didn't investigate why that test fails only in ci. (Reported by Marcus). Yes, please create one for 7.0, I still didnt read how is the new integration process. El 5 oct. 2017 7:11 AM, "Stephane Ducasse" <stepharo.self(a)gmail.com> escribiÃ³: > Tx martin I added > https://pharo.fogbugz.com/f/cases/20492/Update-EPICEA > > Do you have a bug entry for the 7.0 integration or should I create one? > > Stef > > On Tue, Oct 3, 2017 at 7:58 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > I've put ConfigurationOfEpicea 8.2.4 in p6 inbox. > > MartÃn > > > > On Tue, Oct 3, 2017 at 1:40 PM, Martin Dias <tinchodias(a)gmail.com> > wrote: > >> > >> Hi > >> > >> On Tue, Oct 3, 2017 at 11:40 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> > >> wrote: > >>> > >>> Yes, please backport the changes to Pharo 6.1 because the travis builds > >>> are failing a lot with this kind of errors when you have a project with > >>> non-ASCII characters. > >> > >> > >> Ok > >> > >>> > >>> > >>> Probably it makes no sense to enable Epicea in the images used by > >>> SmalltalkCI. Is there some way to disable it? > >> > >> > >> Sure, you can evaluate: EpMonitor reset > >> > >> > >> > >>> > >>> > >>> > >>> On Mon, Oct 2, 2017 at 10:18 AM, Stephane Ducasse > >>> <stepharo.self(a)gmail.com> wrote: > >>>> > >>>> Martin > >>>> > >>>> if you publish a fix for 6.1 we will port it back because this is > >>>> important. > >>>> > >>>> Stef > >>>> > >>>> On Fri, Sep 29, 2017 at 3:55 PM, Martin Dias <tinchodias(a)gmail.com> > >>>> wrote: > >>>> > Now I do not know the best way for you to get the new fixed version. > >>>> > It's > >>>> > too late to include it in P6.1, I guess, so... either add epicea > into > >>>> > metacello configuration or wait until P7. > >>>> > > >>>> > > >>>> > > >>>> > On Fri, Sep 29, 2017 at 5:34 AM, Jan BlizniÄenko > >>>> > <bliznjan(a)fit.cvut.cz> > >>>> > wrote: > >>>> >> > >>>> >> I'm glad it has known reason then, thank you for looking into it, > all > >>>> >> I > >>>> >> was > >>>> >> able to find out was that it relates to non-ascii characters and > that > >>>> >> build > >>>> >> on our production server fails because of that :) > >>>> >> > >>>> >> Jan > >>>> >> > >>>> >> > >>>> >> tinchodias wrote > >>>> >> > On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe < > >>>> >> > >>>> >> > sven@ > >>>> >> > >>>> >> > > wrote: > >>>> >> > > >>>> >> >> > >>>> >> >> > On 23 Sep 2017, at 22:42, Jan BlizniÄenko < > >>>> >> > >>>> >> > bliznjan@.cvut > >>>> >> > >>>> >> > > wrote: > >>>> >> >> > > >>>> >> >> > Hello > >>>> >> >> > > >>>> >> >> > I am having very similar errors from time to time when > manually > >>>> >> >> > loading > >>>> >> >> code > >>>> >> >> > into Pharo from filetree (gitfiletree), but only in one of my > >>>> >> >> > projects > >>>> >> >> which > >>>> >> >> > contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very > >>>> >> >> > same > >>>> >> >> reason > >>>> >> >> > (not able to find why sometimes the error is there and > sometimes > >>>> >> >> > is > >>>> >> >> not), I > >>>> >> >> > did not report it yet, but it is quite annoying. Retrying > >>>> >> >> > loading the > >>>> >> >> > package helps every time. > >>>> >> >> > >>>> >> >> I think was reported before. I believe Ombu somewhere takes an > >>>> >> >> arbitrary > >>>> >> >> chunk of bytes out of an UTF-8 encoded file (like the last 100 > of > >>>> >> >> something > >>>> >> >> like that) and then starts reading that. With UTF-8, a variable > >>>> >> >> length > >>>> >> >> encoding, that can be dangerous because you could end up in the > >>>> >> >> middle > >>>> >> >> of > >>>> >> >> a > >>>> >> >> character, not between encoded character boundaries. This would > >>>> >> >> also > >>>> >> >> explain the randomness, as it is highly dependent on the > contents. > >>>> >> >> > >>>> >> >> ZnUTF8Encoder>>#backOnStream: can be used to make sure you are > >>>> >> >> really > >>>> >> >> at > >>>> >> >> the start of an encoded character. > >>>> >> >> > >>>> >> > > >>>> >> > > >>>> >> > Hello > >>>> >> > > >>>> >> > This issue was reported as: > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail- > while-reading-non-ascii-blocks > >>>> >> > > >>>> >> > My apologies for the bug... I introduced that code as an i/o > >>>> >> > optimization > >>>> >> > but wasn't properly tested. > >>>> >> > > >>>> >> > Thnks Sven, but I finally used stream's #basicNext (as Henrik > >>>> >> > suggested > >>>> >> > in > >>>> >> > fogbugz) which skips forward. > >>>> >> > > >>>> >> > > >>>> >> > Martin > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Sent from: > >>>> >> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >>>> >> > >>>> > > >>>> > >>> > >> > > > >

Oct. 5, 2017

SystemVersion cleanup (or the return of the explicit build number) in latest Pharo 7

by Torsten Bergmann

Hi, as you all know Pharo 7 is built using sources from github and a new bootstrap process. The first Pharo 7 images [1] unfortunately were hard to distinguish - the initial problem was described in [2] Guille tried to address this by adding a build number again [3] but unfortunately he mixed it into the existing suffix of the class SystemVersion. There was also some other trouble afterwards: - the highestUpdate was still not set by the bootstrap process, which made some code unloadable (like Artefact who's config is checking if it is above a certain update number) - with Guilles fix the build number had to be parsed from the suffix string - one was still not able to distinguish 32/64 bit images - the SystemVersion class and the according tests were still ugly So I reviewed all this more deeply and cleaned SystemVersion as well as the tests while trying to stay as compatible as possible. Thanks a lot to Pavel and Esteban who helped me sorting things out, especially in git and the bootstrap process. How does it look now ==================== 1. Our system type is still called "Pharo" ;) SystemVersion current type -> 'Pharo' 2. we still continue with major and minor versioning (leaving out patch versions), so currently work is done for Pharo 7.0 SystemVersion current major -> 7 SystemVersion current minor -> 0 SystemVersion current majorMinorVersion -> 'Pharo7.0' 3. the identification string now has a "+" sign inside to separate the build meta informations following the given rule 10 from http://semver.org So the full image version now looks like this: SystemVersion current imageVersionString -> 'Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit)' 4. the suffix is currently "alpha" and may be changed depending on release status SystemVersion current suffix -> 'alpha' 5. the build number is stored as an explicit ivar in SystemVersion now SystemVersion current build -> 168 Note that the build number is explicitly set during the bootstrap process from the outside and increased over time with each new build. It represents the CI build number of #development branch now, see [4] on CI server 6. the github SHA commit hash is accessible too: SystemVersion current commitHash -> '30fc9bbe79922877706ecd842f8aef6822cdcdd9' which corresponds in this case to the last commit in #development branch https://github.com/pharo-project/pharo/commit/30fc9bbe79922877706ecd842f8ae… 7. the version includes now also the 32/64 bit distinction: Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit) or Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (64 Bit) Additionally ============ - the version is displayed in SystemReporter and the AboutBox (Screenshot attached), please use this to identify the image easily - the #highestUpdate is calculated dynamically with code in the image (but it is there only for compatibility reasons). SystemVersion current highestUpdate -> "70168" We might easily catch the 999 build mark now and then run into 71000 which might still be Pharo 7.0 instead of 7.1. (which means first two digits of update number will then NOT correspond to major/minor version anymore). So better avoid #highestUpdate as a meaningful number for loading code or other. - also note if you contribute with an own PR (in your own fork on github) the build number is the build number of you PR specific CI build. Once your PR is reviewed and merged it is the regular Pharo image build number again. - you can reuse SystemVersion for you own apps built on top of Pharo: "MyKillerApp-1.0+beta (64 Bit)" can be easily created with: (SystemVersion major: 1 minor: 0 suffix: 'beta') type: 'MyKillerApp'; yourself - if you report a bug on bugs.pharo.org it would be good to note down the full version of the image you used as found in the About box. This allows to better reproduce wrong behavior that only happens in a specific image Thanks T. [1] http://files.pharo.org/image/70/ [2] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1309… [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1310… [4] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2017

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

by Esteban Lorenzano

then replacing "byte *â with ByteArray ? > On 5 Oct 2017, at 15:42, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > 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 >> >> >> >>> >>> 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 >>>>> >>>> >>>> >>> >> >> > <crash.dmp>

Oct. 5, 2017