- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by tesonep＠gmail.com

That could be nice!! Maybe having a prototype allows us to see more usages! On Wed, Apr 4, 2018 at 9:58 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Would it be possible to instead have a #haltIf object to which you can > send additional conditions? > > E.g. > > self haltIf insideTest > self haltIf outsideTest > > Makes it (imho) a bit more readable, adds just a single method to Object, > and allows for more potential extensions... > > self haltIf nil. > self haltIf count: 3. > > etc? > > Peter > > On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > >> >> > Le 4 avr. 2018 Ã 04:34, Sean P. DeNigris <sean(a)clipperadams.com> a >> Ã©crit : >> > >> > demarey wrote >> >> What about haltIfTestExecutionEnvironment and >> >> haltIfDefaultExecutionEnvironment ? >> > >> > I thought the names were okay. What did you think was unclear about >> them? >> >> At a first look #haltInsideTest and #haltOutsideTest do not tell me that >> they are conditional breakpoints. >> maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest >> > > -- Pablo Tesone. tesonep(a)gmail.com

April 4, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Peter UhnÃ¡k

Would it be possible to instead have a #haltIf object to which you can send additional conditions? E.g. self haltIf insideTest self haltIf outsideTest Makes it (imho) a bit more readable, adds just a single method to Object, and allows for more potential extensions... self haltIf nil. self haltIf count: 3. etc? Peter On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > > > Le 4 avr. 2018 Ã 04:34, Sean P. DeNigris <sean(a)clipperadams.com> a > Ã©crit : > > > > demarey wrote > >> What about haltIfTestExecutionEnvironment and > >> haltIfDefaultExecutionEnvironment ? > > > > I thought the names were okay. What did you think was unclear about them? > > At a first look #haltInsideTest and #haltOutsideTest do not tell me that > they are conditional breakpoints. > maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest >

April 4, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Christophe Demarey

> Le 4 avr. 2018 Ã 04:34, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > demarey wrote >> What about haltIfTestExecutionEnvironment and >> haltIfDefaultExecutionEnvironment ? > > I thought the names were okay. What did you think was unclear about them? At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest

April 4, 2018

Small lint cleanups for Zodiac

by Torsten Bergmann

Hi Sven, attached some small lint cleanups for Zodiac as I was not able to commit to Zodiac on SThub. Changes mentioned below. This was done in Pharo 7 but based on latest MCZ's. Thx T. ------------------------------------------------------------------------------ Name: Zodiac-Core-TorstenBergmann.48 Author: TorstenBergmann Time: 4 April 2018, 7:45:15.792684 am UUID: 2c097b10-6125-0d00-ae7c-de9200a97a05 Ancestors: Zodiac-Core-SvenVanCaekenberghe.47 use common "initialization" category to prevent lint problems in Pharo 7 ------------------------------------------------------------------------------ Name: Zodiac-Tests-TorstenBergmann.20 Author: TorstenBergmann Time: 4 April 2018, 7:51:47.289684 am UUID: 54ced027-6125-0d00-ae7d-4b5100a97a05 Ancestors: Zodiac-Tests-SvenVanCaekenberghe.19 add comment for ZdcByteArrayManagerTests ------------------------------------------------------------------------------ Name: Zodiac-Tests-TorstenBergmann.21 Author: TorstenBergmann Time: 4 April 2018, 8:08:38.372684 am UUID: 4cb51464-6125-0d00-ae7e-d1a000a97a05 Ancestors: Zodiac-Tests-TorstenBergmann.20 Lint cleanup: use #assert:equals: and remove unnecessary nots

April 4, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Sean P. DeNigris

demarey wrote > What about haltIfTestExecutionEnvironment and > haltIfDefaultExecutionEnvironment ? I thought the names were okay. What did you think was unclear about them? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 4, 2018

Re: [Pharo-dev] SSL error on windows 7

by Stephane Ducasse

Thanks you for helping us! On Tue, Apr 3, 2018 at 2:30 PM, webwarrior <reg(a)webwarrior.ws> wrote: > ZnClient new url: 'https://github.com'; get > > Windows 7 64-bit: > Error (Error: SSL Exception: connect failed [code:-5]) both in Pharo6 and > Pharo7 > > Windows 10 64-bit: > Works fine in both Pharo6 and Pharo7 > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 3, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Christophe Demarey

Nice addition! I should say that names are not really intention revealing. What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ? > Le 2 avr. 2018 Ã 21:12, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > Hi, > > As we can not very easily decide if we are inside a test execution or not there was the idea to have special #halt messages > > https://pharo.fogbugz.com/f/cases/20151/new-halt-messages <https://pharo.fogbugz.com/f/cases/20151/new-halt-messages> > > This PR implements them: > > https://github.com/pharo-project/pharo/pull/1177 <https://github.com/pharo-project/pharo/pull/1177> > > There is now #haltIfInsideTest and #haltfOutsideTest. In addition, the PR adds a helper method to make checking if the current > execution environment is a test run a bit easier: "CurrentExecutionEnvironment value isTestâ. > > Marcus

April 3, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Stephane Ducasse

+ 1 I really want to use these new friends because I use this pattern really a lot when coding. Tx I wanted to do that during the last sprint. On Tue, Apr 3, 2018 at 9:09 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 3 Apr 2018, at 00:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 3 April 2018 at 03:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> As we can not very easily decide if we are inside a test execution or not >> there was the idea to have special #halt messages >> >> https://pharo.fogbugz.com/f/cases/20151/new-halt-messages >> >> This PR implements them: >> >> https://github.com/pharo-project/pharo/pull/1177 >> >> There is now #haltIfInsideTest and #haltfOutsideTest. I > > > Should the standard #halt default to one of these? Or left as is? (I've no > clue, just the question arises). > > I would keep it for now as is.. it is the simplest to have one âhaltâ that > always halts and then variants (there > is halt once, too, which makes often more sense than #halt). > > Marcus >

April 3, 2018

Re: [Pharo-dev] [Vm-dev] VM git commit hash (was: Image crashing on startup, apparently during GC)

by Ben Coman

On 3 April 2018 at 07:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Alistair, Hi Ben, > > > > On Apr 2, 2018, at 9:28 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > > > > Hi Ben, > > > > > >> On 2 April 2018 at 15:42, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> > >>> On 2 April 2018 at 20:26, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >>> > >>> > >>>> On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote: > >>>> Hi Alistair, > >>>> > >>>> _,,,^..^,,,_ (phone) > >>>> > >>>>> On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >>>>> > >>>>> git doesn't provide a substitution mechanism like sccs, but the > script > >>>>> we have that embeds the date can just as easily embed the hash. In > >>>>> .git_filters/RevDateURL.smudge there's a line that retrieves the > >>>>> commit date from git: > >>>>> > >>>>> $date = `git log --format=%ad -1`; > >>>>> > >>>>> to get the (short) hash we can simply add: > >>>>> > >>>>> $shorthash = `git log --format=%h -1`; > >>>>> > >>>>> The string substitution can then proceed as for the date. > >>>>> > >>>>> I think it would be worthwhile having both the date and hash in the > >>>>> --version info. > >>>>> > >>>>> I'm happy to add this in and update the --version output if there's > >>>>> general agreement. > >>>> > >>>> Yes please!!! The conventional alternative is to invoke git log from > >>>> the makefiles and lass in the commit hash as a compiler-line default > >>>> me. But this is messy and slows down compilation (unless there is a > >>>> special rule for just one file, and that's fragile). I much prefer > >>>> having the commit somewhere in source. > >>> > >>> Done: > >>> > >>> $ git log --oneline | head > >>> 5a5b1c7 vm version string: add commit short hash > >>> 4c4686e Skip SUnit testing in Sista builds > >>> 79c0809 Merge pull request #230 from smalltalking/Cog > >>> 804ed5c Fixed typo in the download URL > >>> > >>> > >>> $ products/cogspur64linuxht/pharo --version > >>> 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 > [Production Spur 64-bit VM] > >>> CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b > Apr 1 2018 > >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: > 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 > >>> VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm > $ > >>> Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $ > >> > >> > >> Maybe rather than just "Hash:" could it be more explicit as "GitHash:" > or even "GitSHA1:" > >> One day the algorithm is likely to change... "Moving Git past SHA-1" ( > https://lwn.net/Articles/715716/) > >> and it may be useful later to be able to distinguish. > > > > I like "GitHash" as it may not be obvious what the hash refers to for > > a newcomer. Even if/when git moves away from sha1, from a cli/ui > > perspective presumably it will still just be "the hash". > > Commit Hash? > I see Alistar went with this one. A reasonable choice. cheers -ben > Commit Hash (git)? > C Commit Hash? > Repository Commit Hash? > > We've already moved from one sccs to another for the C code and may move > again if anyone improves on git, which is not inconceivable. > > >>> Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm > $ > >>> Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 > 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > >>> plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash > [default: /home/alistair/vmmaker/opensmalltalk-vm/products/ > cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/] > >>> > >>> > >>> As expected, the hash is also included in: > >>> > >>> - the VirtualMachine object (in Pharo, and the equivalent in squeak) > >> > >> > >> I presume this is what shows up under System > System Reporter ? > > > > Yes. > > > > > >>> - crash.dmp > >>> - kill -USR1 output > >>> > >>> > >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 > >>> if anyone wants to take a look. > >> > >> > >> > >> An interesting insight for me into how the version info is generated. > thx. > > > > Glad it was useful. :-) > > > > Thanks for your feedback. I'll update the PR (probably tomorrow). > > > > Cheers, > > Alistair >

April 3, 2018

Re: [Pharo-dev] Loading code with iceberg

by Guido Chari

Hi Guille, Thank you. Simple enough :). I was facing the same problem. I am not sure who is in charge of the iceberg documentation (Readme in the repo) but I would suggest adding that info within the Iceberg API section. Best Regards, Guido. 2018-04-03 11:24 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi Javier, you should register your repository, otherwise it will be just > garbage collected: > > [[[ > myRepository register. > ]]] > > On Sun, Apr 1, 2018 at 4:57 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> > wrote: > >> We are loading some code using Iceberg API in pharo6.1. That works fine, >> the problem we have is that when I open Iceberg browser no repo is shown >> up. Maybe you can help me find what we are doing wrong. We first update >> iceberg, then load our repo, code is below. >> >> Cheers, >> Pocho. >> >> ---- >> >> Author useAuthor: 'LoadSqueakNOS' during: [ >> "First update Iceberg" >> >> MetacelloPharoPlatform select. >> #( >> 'BaselineOfTonel' >> 'BaselineOfLibGit' >> 'BaselineOfIceberg' >> 'Iceberg-UI' >> 'Iceberg-Plugin-GitHub' >> 'Iceberg-Plugin' >> 'Iceberg-Metacello-Integration' >> 'Iceberg-Libgit-Tonel' >> 'Iceberg-Libgit-Filetree' >> 'Iceberg-Libgit' >> 'Iceberg' >> 'Iceberg-Pharo6' >> 'LibGit-Core' >> 'MonticelloTonel-Tests' >> 'MonticelloTonel-Core' >> 'MonticelloTonel-FileSystem' ) >> do: [ :each | (each asPackageIfAbsent: [ nil ]) ifNotNil: >> #removeFromSystem ]. >> >> Metacello new >> baseline: 'Iceberg'; >> repository: 'github://pharo-vcs/iceberg:v0.6.8'; >> load. >> ] >> >> "Based on the same file from the pharo-vm project" >> >> myRepository := IceRepositoryCreator new >> url: 'git@github.com:nopsys/CogNOS.git'; >> subdirectory: 'Image-src'; >> createRepository. >> (myRepository addPackageNamed: 'SqueakNOS') loadLatest. >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > > > > 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> >

April 3, 2018