- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Stephane Ducasse

Hi stephan not really this is more "not thinking in terms of large dependencies" :) Stef On Mon, Nov 27, 2017 at 12:26 PM, stephan <stephan(a)stack.nl> wrote: > On 27-11-17 11:02, Alistair Grant wrote: >> >> As >> we've seen from Pillar and Magritte, the more dependencies the greater >> the maintenance costs and potential for incompatibility. > > > That conclusion is not supported by the actual code. The maintenance costs > for Pillar were high because of ignoring existing users of the code and bad > Metacello practices. > > Stephan > >

Nov. 27, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Stephane Ducasse

Hi alistair I understand. If this is a useful combination my practice is to create a separate projects which loads both. For Pillar and Magritte this is another story. When magritte is used deep down in the core of Magritte then you end up being forced to load magritte even when you do not need it. I was a naive design decision. Stef On Mon, Nov 27, 2017 at 11:02 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On 26 November 2017 at 22:39, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi Alistair >> >> If you want help I can add a baseline that automtically load DataFrame. >> Because users should not load by themselves external project. > > Thanks for the offer, but Pharo-Chrome isn't actually dependent on > DataFrame. I just used it in an example in the README as it makes > inspecting the results easy (it's possible to inspect the results > without DataFrame, you'll just be looking at an Array of Arrays). As > we've seen from Pillar and Magritte, the more dependencies the greater > the maintenance costs and potential for incompatibility. If there's a > compelling reason to automatically load DataFrame I'm happy to do > that, but at the moment I'm not seeing it. > > Cheers, > Alistair > > > >> Stef >> >> On Sat, Nov 25, 2017 at 3:57 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> Alistair Grant wrote >>>> https://github.com/PolyMathOrg/DataFrame >>> >>> Cool, thanks! I didn't know about this project. >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> >

Nov. 27, 2017

Re: [Pharo-users] How do you store and manage small programs?

by Stephane Ducasse

Super cool tshirt! Stef On Mon, Nov 27, 2017 at 1:18 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > It is useful for presentations. > > https://www.youtube.com/watch?v=JhmmoEtAq20&t=269s > > Phil > > On Mon, Nov 27, 2017 at 1:06 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Wow - I never noticed that extension - thatâs amazing. >> >> On 27 Nov 2017, at 10:56, phil(a)highoctane.be wrote: >> >> QuickAccess is also a great option. >> >> https://pharoweekly.wordpress.com/2015/11/06/quickaccess/ >> >> On Mon, Nov 27, 2017 at 11:16 AM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >>> >>> On 26 November 2017 at 13:07, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>> > Hi Andy >>> > >>> > As you saw there are plenty of solutions. >>> > >>> > Now what I learned is that it is often better in the long to have a >>> > little object because suddenly >>> > it opens your mind and you realise that you can teach him something >>> > more. >>> > >>> > So I often find myself realising that I created some class methods and >>> > that it was stupid >>> > better have a real little object because it can do more and in >>> > particular for open new path >>> > >>> > So now I do not use scripts but plain little classes with nice little >>> > printOn: methods and arguments >>> > to get customized. >>> >>> +1 >>> >>> And if you create a class method to do the most common operation(s), >>> you can add the "<script>" pragma and a button appears in the browser >>> to run the operation. >>> >>> Cheers, >>> Alistair >>> >>> >> >> >

Nov. 27, 2017

Re: [Pharo-users] Removing instance variables doesn't recompile the methods

by abdelghani ALIDRA

Hi Peter, Yes. More basically : 1) you compile a method with parameter anObject 2) you add an instance anObject 3) you try to modify/compile the method and you have a message error. Maybe there should be a kind of warning message Abdelghani -------------------------------------------- En date deÂ : Lun 27.11.17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> a Ã©critÂ : Objet: Re: [Pharo-users] Removing instance variables doesn't recompile the methods Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Cc: "abdelghani ALIDRA" <alidrandco(a)yahoo.fr> Date: Lundi 27 novembre 2017, 10h21 As far as I know this has been a _feature_ for a very long time.Automatic recompiling methods is not the best idea, because: 1) you compile a method with temp var "hello" that uses inst var "world"2) you add a inst var "hello"3) you remove "world"4) trying to recompile the method will fail, because suddenly there's a clash between temp var "hello" and inst var "hello" Don't forget that the methods are compiled, not interpreted. So this behavior is expected. Peter On Mon, Nov 27, 2017 at 6:03 AM, Ben Coman <btc(a)openinworld.com> wrote: Thanks for reporting Abdelghani.Now it would be doubly useful if you could isolate which build introduced the problem.PharoLauncher can be used to help bisect working/non-working images. cheers -ben On 27 November 2017 at 04:08, abdelghani ALIDRA via Pharo-users <pharo-users(a)lists.pharo.org> wrote: ---------- Forwarded message ---------- From:Â abdelghani ALIDRA <alidrandco(a)yahoo.fr> To:Â "pharo-users(a)lists.pharo. org" <pharo-users(a)lists.pharo.org> Cc:Â Bcc:Â Date:Â Sun, 26 Nov 2017 20:08:29 +0000 (UTC) Subject:Â Removing instance variables doesn't recompile the methods Hi, In a fresh pharo 6 image, I add a class with an instance variable x and implement accessors. Then I write a test method for the accessors of x MyClassTest>>testReadWriteX Â Â Â self assert (MyClass new x: 0) x equals: 0 I run the test and obviously it is green BUT I remove the instance variable x. Obviously, the accessors are broken and the test should be red when I execute it again but it is not!!! I can even change the class again (to recompile it I thought) or even load the code in a new image and the tests are still green. I can also invoque the broken methods in a playground or in an inspector : MyClass new x: 0; increment; x then printIt. and astonishingly 1 is printed. The only way to detect the error is to recompile the method but this does not happen (maybe it should) when instance variables are modified or removed in the class (even when you use the refactoring tool!) I think this is annoying because one can no more really trust his tests. Cheers Abdelghani

Nov. 27, 2017

Re: [Pharo-users] Removing instance variables doesn't recompile the methods

by abdelghani ALIDRA

Hi Ben, I will try to see. I dont have my PC right now Abdelghani -------------------------------------------- En date deÂ : Lun 27.11.17, Ben Coman <btc(a)openinworld.com> a Ã©critÂ : Objet: Re: [Pharo-users] Removing instance variables doesn't recompile the methods Ã: "abdelghani ALIDRA" <alidrandco(a)yahoo.fr>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Date: Lundi 27 novembre 2017, 6h03 Thanks for reporting Abdelghani.Now it would be doubly useful if you could isolate which build introduced the problem.PharoLauncher can be used to help bisect working/non-working images. cheers -ben On 27 November 2017 at 04:08, abdelghani ALIDRA via Pharo-users <pharo-users(a)lists.pharo.org> wrote: ---------- Forwarded message ---------- From:Â abdelghani ALIDRA <alidrandco(a)yahoo.fr> To:Â "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org> Cc:Â Bcc:Â Date:Â Sun, 26 Nov 2017 20:08:29 +0000 (UTC) Subject:Â Removing instance variables doesn't recompile the methods Hi, In a fresh pharo 6 image, I add a class with an instance variable x and implement accessors. Then I write a test method for the accessors of x MyClassTest>>testReadWriteX Â Â Â self assert (MyClass new x: 0) x equals: 0 I run the test and obviously it is green BUT I remove the instance variable x. Obviously, the accessors are broken and the test should be red when I execute it again but it is not!!! I can even change the class again (to recompile it I thought) or even load the code in a new image and the tests are still green. I can also invoque the broken methods in a playground or in an inspector : MyClass new x: 0; increment; x then printIt. and astonishingly 1 is printed. The only way to detect the error is to recompile the method but this does not happen (maybe it should) when instance variables are modified or removed in the class (even when you use the refactoring tool!) I think this is annoying because one can no more really trust his tests. Cheers Abdelghani

Nov. 27, 2017

Re: [Pharo-users] How do you store and manage small programs?

by Offray Vladimir Luna CÃ¡rdenas

Yes. Plenty of solutions, from just open your Playground in a scripts folder, to QuickAccess, to objects, to embedding scripts into more complete data narratives. They serve different purposes, so explore them and see which ones serves better your taste and user case. Cheers, Offray On 26/11/17 07:07, Stephane Ducasse wrote: > Hi Andy > > As you saw there are plenty of solutions. > > Now what I learned is that it is often better in the long to have a > little object because suddenly > it opens your mind and you realise that you can teach him something more. > > So I often find myself realising that I created some class methods and > that it was stupid > better have a real little object because it can do more and in > particular for open new path > > So now I do not use scripts but plain little classes with nice little > printOn: methods and arguments > to get customized. > > Stef > > On Sat, Nov 25, 2017 at 6:34 PM, Andy Burnett > <andy.burnett(a)knowinnovation.com> wrote: >> I have just created a couple of small playground scripts that do some useful >> data wrangling. The chances are that I will reuse them from time to time, >> but with tweaks. Does version 6 Have some way to store them? I think I am >> after a sort of scripts catalogue. >

Nov. 27, 2017

Re: [Pharo-users] How do you store and manage small programs?

by phil＠highoctane.be

It is useful for presentations. https://www.youtube.com/watch?v=JhmmoEtAq20&t=269s Phil On Mon, Nov 27, 2017 at 1:06 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Wow - I never noticed that extension - thatâs amazing. > > On 27 Nov 2017, at 10:56, phil(a)highoctane.be wrote: > > QuickAccess is also a great option. > > *https://pharoweekly.wordpress.com/2015/11/06/quickaccess/ > <https://pharoweekly.wordpress.com/2015/11/06/quickaccess/>* > > On Mon, Nov 27, 2017 at 11:16 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> On 26 November 2017 at 13:07, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> > Hi Andy >> > >> > As you saw there are plenty of solutions. >> > >> > Now what I learned is that it is often better in the long to have a >> > little object because suddenly >> > it opens your mind and you realise that you can teach him something >> more. >> > >> > So I often find myself realising that I created some class methods and >> > that it was stupid >> > better have a real little object because it can do more and in >> > particular for open new path >> > >> > So now I do not use scripts but plain little classes with nice little >> > printOn: methods and arguments >> > to get customized. >> >> +1 >> >> And if you create a class method to do the most common operation(s), >> you can add the "<script>" pragma and a button appears in the browser >> to run the operation. >> >> Cheers, >> Alistair >> >> >> > >

Nov. 27, 2017

Re: [Pharo-users] How do you store and manage small programs?

by Tim Mackinnon

Wow - I never noticed that extension - thatâs amazing. > On 27 Nov 2017, at 10:56, phil(a)highoctane.be wrote: > > QuickAccess is also a great option. > > https://pharoweekly.wordpress.com/2015/11/06/quickaccess/ <https://pharoweekly.wordpress.com/2015/11/06/quickaccess/> > > On Mon, Nov 27, 2017 at 11:16 AM, Alistair Grant <akgrant0710(a)gmail.com <mailto:akgrant0710@gmail.com>> wrote: > On 26 November 2017 at 13:07, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > > Hi Andy > > > > As you saw there are plenty of solutions. > > > > Now what I learned is that it is often better in the long to have a > > little object because suddenly > > it opens your mind and you realise that you can teach him something more. > > > > So I often find myself realising that I created some class methods and > > that it was stupid > > better have a real little object because it can do more and in > > particular for open new path > > > > So now I do not use scripts but plain little classes with nice little > > printOn: methods and arguments > > to get customized. > > +1 > > And if you create a class method to do the most common operation(s), > you can add the "<script>" pragma and a button appears in the browser > to run the operation. > > Cheers, > Alistair > > >

Nov. 27, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by stephan

On 27-11-17 11:02, Alistair Grant wrote: > As > we've seen from Pillar and Magritte, the more dependencies the greater > the maintenance costs and potential for incompatibility. That conclusion is not supported by the actual code. The maintenance costs for Pillar were high because of ignoring existing users of the code and bad Metacello practices. Stephan

Nov. 27, 2017

Re: [Pharo-users] How do you store and manage small programs?

by Alistair Grant

On 27 November 2017 at 11:16, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 26 November 2017 at 13:07, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi Andy >> >> As you saw there are plenty of solutions. >> >> Now what I learned is that it is often better in the long to have a >> little object because suddenly >> it opens your mind and you realise that you can teach him something more. >> >> So I often find myself realising that I created some class methods and >> that it was stupid >> better have a real little object because it can do more and in >> particular for open new path >> >> So now I do not use scripts but plain little classes with nice little >> printOn: methods and arguments >> to get customized. > > +1 > > And if you create a class method to do the most common operation(s), > you can add the "<script>" pragma and a button appears in the browser > to run the operation. Often better than a printOn: is to create a #gtInspectIn: method, allowing you to display tables, graphs, etc. as appropriate in the inspector. Actually, this has worked so well that I haven't written a "real UI" for anything I use in my personal environment, which includes downloading media, all my note keeping, tracking finances, etc. Cheers, Alistair

Nov. 27, 2017