November 2017 - Pharo-users

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Guillermo Polito

On Wed, Nov 15, 2017 at 11:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> >>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> And just putting it back to gray? As "not run"? >>>> >>> >>> We can implement any logic. >>> Personally I need current behaviour. >>> >> >> But it is not about you personally. It is about implementing the most >> common and the less strange for newcomers. >> > > To know what is the most common case people should tell personal opinion. > And in this thread only Richard was against current logic. > But you're assuming here that: - people that is not reading this email do not care and don't have a say - so pleople that is not subscribed to the mailing list don't care - and that includes newbies Our role of experienced guys it not only look after "our" best defaults. But also after the defaults of people without experience. I think that setting the button back to gray is a good behaviour. - it is the same thing that happens once you modify a method (which is what is happening during debugging) - it explicitly says "please rerun the test because you may have introduced side effects" Unless you make the debugger more intelligent, you cannot be sure that the result you obtained at the end of the test is really reproducible. And moreover, to be able to make such assumption you should be an expert that understands how the underlying framework behaves. > > >> >> >>> >>> >>>> >>>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov < >>>> dionisiydk(a)gmail.com> wrote: >>>> >>>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>> >>>>>> Ben Coman wrote >>>>>> > Or it could go to Amber, half-way between green & red to mean >>>>>> probably >>>>>> > correct. >>>>>> >>>>>> Ha ha. >>>>>> >>>>>> Again, it seems that just automatically rerunning the test >>>>>> immediately after >>>>>> a human-manipulated run and setting the color based on that second run >>>>>> addresses all points on both sides, no? >>>>>> >>>>> >>>>> Except that sometimes we are debugging slow test and running it second >>>>> time automatically after "proceed" can be not appropriate. >>>>> We are talking about single test run. If user have any doubts about >>>>> result It is his responsibility to rerun the test. User knows what he is >>>>> doing when he debug and fix the test. No intelligence is required here. >>>>> >>>>> And anyway current fix just provides consistent behaviour to debugging >>>>> from explicit breakpoint/halt. In that case the result was always in sync >>>>> with debug session. >>>>> >>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> 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> >>>> >>> >>> >> >> >> -- >> >> >> >> 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> >> > > -- 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

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Denis Kudriashov

2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> >> 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> And just putting it back to gray? As "not run"? >>> >> >> We can implement any logic. >> Personally I need current behaviour. >> > > But it is not about you personally. It is about implementing the most > common and the less strange for newcomers. > To know what is the most common case people should tell personal opinion. And in this thread only Richard was against current logic. > > >> >> >>> >>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com >>> > wrote: >>> >>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>> >>>>> Ben Coman wrote >>>>> > Or it could go to Amber, half-way between green & red to mean >>>>> probably >>>>> > correct. >>>>> >>>>> Ha ha. >>>>> >>>>> Again, it seems that just automatically rerunning the test immediately >>>>> after >>>>> a human-manipulated run and setting the color based on that second run >>>>> addresses all points on both sides, no? >>>>> >>>> >>>> Except that sometimes we are debugging slow test and running it second >>>> time automatically after "proceed" can be not appropriate. >>>> We are talking about single test run. If user have any doubts about >>>> result It is his responsibility to rerun the test. User knows what he is >>>> doing when he debug and fix the test. No intelligence is required here. >>>> >>>> And anyway current fix just provides consistent behaviour to debugging >>>> from explicit breakpoint/halt. In that case the result was always in sync >>>> with debug session. >>>> >>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> 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> >>> >> >> > > > -- > > > > 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> >

Nov. 15, 2017

Re: [Pharo-users] Stream API

by Prof. Andrew P. Black

> On 14 Nov 2017, at 14:07 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am curious though, why do you need it ? > > I mean, I got away (and try hard) to only use 1-element peeking and managed to implement STON, NeoJSON, NeoCSV, Stomp, PostgresSQL, Redis, and other protocols. > > A syntax that really requires multi element peeking is not so common. I need it in my present situation because Iâm inside a framework that thinks that it owns the Stream (viz, inside SmaCC). I can write a custom action in the scanner for, in my case, <newline> tokens, that deals with indentation. Sometimes that action need to look ahead to do the right thing. For example, if the current line is completely blank, it canât be an indentation error, and does not re-set the current indentation to zero. I need to make such determinations from inside the newline method, and then reset the state of the stream so that the rest of the SmaCC-generated parser is undisturbed. In a framework like a PEG, you get a similar situation. A parser in a PEG should either succeed, and consume input, or fail, and leave the input where it was. This is true not just for simple parsers that read one character, but also for compound parsers that may perform arbitrary actions before they fail. This usually works by saving and resetting the stream state (but also maintaining a cache in the case of a Packrat Parser). In general, this is a modularity issue. Although globally, one may be able to limit lookahead, locally, itâs not so easy. An alternative to saving a restoring state is to allow arbitrary putback, as in OS6 streams. But I think that state-saving is more useful, even if it is less general. Andrew

Nov. 15, 2017

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

by Alistair Grant

Hi Sean, On 15 November 2017 at 10:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote >> Sorry (and to Offray) for the trouble, but thanks for persevering. > > Not at all! Thanks for updating the library :) > > > Alistair Grant wrote >> Would you mind setting a breakpoint in >> AKGOSProcess>>command:arguments:, printing the command and arguments >> and making sure that the --user-data-dir exists? > > Sure: > command = '/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome' > "(after I added the leading slash)". I've added the slash, so hopefully you won't have to do this again. > args = #('--user-data-dir=/tmp/pharo/GoogleChrome/debugSession' > '--remote-debugging-port=9222') > > > Alistair Grant wrote >> and making sure that the --user-data-dir exists? > > It does. > > Also, as a sanity check, the following works: > OSSUnixSubprocess new > command: 'open'; > arguments: { 'http://www.pharo.org' }; > run > As well as from the Terminal: > $ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome > --user-data-dir=/tmp/pharo/GoogleChrome/debugSession > --remote-debugging-port=9222 > > > Alistair Grant wrote >> Also, as Mariano requested, can you confirm that it is MacOS, which >> version of Pharo, and a 32 bit VM? > > I think I'm on 32 bit. I created a fresh 6.1 from Launcher. How can one tell > for sure if one is in a 32 vs 64 bit image? OSPlatform current isUnix32 But if the OSSUnixSubprocess command above is working it must be 32 bit. I'm struggling to figure this one out. Sorry for making you do all the work, but the only things I can think of at the moment are: 1. If chrome is your default browser, can you try replacing the explicit command with "open" since it seems to work above, i.e. in OSXChromePlatform class>>openChromeWith: just set executableLocation := 'open'. 2. Try just opening the browser without any optional arguments, i,e, OSSUnixSubprocess new command: '/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome'; arguments: { 'http://www.pharo.org' }; run > Latest update: #60520 > > Operating System/Hardware > ------------------------- > Mac OS 1013.1 intel > > Virtual Machine > --------------- > /Users/sean/Documents/Pharo/vms/61-x86/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple > LLVM 6.1.0 (clang-602.0.53) > VMMaker versionString VM: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 > 12:42:21 2017 -0700 $ Plugins: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Nov. 15, 2017

Re: [Pharo-users] Stream API

by Guillermo Polito

I have a meta-comment here. As a community I feel sometimes that we are trying to make people converge. "Somebody already wrote a transducers library, I cannot write another transducers library, we have to merge". Now, I understand that sometimes we don't have the "manpower" to solve all the problems in the world, but let's not coerce people to "converge" just for converging. Most of the times, different libraries are implemented with different tradeoffs and different use case scenarios, and even with different aesthetic preferences. I think I'm saying nothing strange if I say that there is no silver bullet :). Some people may implement their own library for fun: - I don't want to prevent people from having fun - I don't want to prevent myself from having fun So Steffen, please deliver something nice, with nice docs, and have fun and thanks :) On Wed, Nov 15, 2017 at 11:12 AM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Short: No. =) > > Actually, the <~ notation was originally proposed by another Smalltalker > on the vwnc list. The idea was that <~ visualizes the flow into the > variable, which I find nice (see first expression). However, I do > understand that this alienates others. Hence, I am non-religious about the > matter; I could even live with both messages coexisting. > > Denis I agree. I do not like to code in reverse order. >> >> I like abstraction. But I think names and order of computation should be >>> changed to be more Smalltalk friendly. Because now it looks like Haskell >>> with right to left order: >>> >>> squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000). >>> fileOut writeStream <~ #isSeparator filter <~ fileIn readStream. >>> >>> Is there any reason to not change it? >>> >> > Best, Steffen > > -- 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

Nov. 15, 2017

Re: [Pharo-users] Stream API

by Steffen MÃ¤rcker

Please note, the port on GitHub is not the most recent version. I had trouble porting it to Pharo and code exchange in general. For now it's unfinished due to a lack of time. Am .11.2017, 16:30 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: > I forgot to mention, that the most recent code for Pharo is already on > Github: https://github.com/Pharophile/Transducers > > Reducers was the name of the first very first implementation. > > (In fact, I was originally inspired by clojures Reducers lib. After > implementing it in Smalltalk, I developed the concept further. Later I > found out, that the clojure guys did the same in parallel and ended up > with the same abstraction but a differnt name. Hence I decided change > the name in order to make the relation clear.) > > Am .11.2017, 16:18 Uhr, schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> >>> On 14 Nov 2017, at 16:00, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> Hi, >>> > <---Schnitt---> >>> >>> No. Transducers is my side project. I've implemented a package for >>> VisualWorks. Unfortunately, I did not finish the port to Pharo yet, >>> simply due to a lack of time. Originally, transducers evolved in the >>> clojure community. I figured, the concept a good fit for Smalltalk and >>> adapted it accordingly. (My thesis is on conditional probabilities in >>> model-checking of probabilistic systems.) >>> > <---Schnitt---> >>> >>> http://www.cincomsmalltalk.com/publicRepository/Transducers.html >>> https://clojure.org/reference/transducers >>> Plus some mails on this list and more on the vwnc list. Feel free to >>> ask; I understand, that the package comment has lots of potential for >>> improvement to help understanding. >>> >>> Best, Steffen >> >> Some code seems to be here: http://smalltalkhub.com/#!/~cdlm/Experiments >> >> Not sure if it is complete or what the relation is, or the difference >> between transducers and reducers ... >> >> > >

Nov. 15, 2017

Re: [Pharo-users] Stream API

by Steffen MÃ¤rcker

Short: No. =) Actually, the <~ notation was originally proposed by another Smalltalker on the vwnc list. The idea was that <~ visualizes the flow into the variable, which I find nice (see first expression). However, I do understand that this alienates others. Hence, I am non-religious about the matter; I could even live with both messages coexisting. > Denis I agree. I do not like to code in reverse order. > >> I like abstraction. But I think names and order of computation should be >> changed to be more Smalltalk friendly. Because now it looks like Haskell >> with right to left order: >> >> squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000). >> fileOut writeStream <~ #isSeparator filter <~ fileIn readStream. >> >> Is there any reason to not change it? Best, Steffen

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Guillermo Polito

On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> And just putting it back to gray? As "not run"? >> > > We can implement any logic. > Personally I need current behaviour. > But it is not about you personally. It is about implementing the most common and the less strange for newcomers. > > >> >> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>> >>>> Ben Coman wrote >>>> > Or it could go to Amber, half-way between green & red to mean probably >>>> > correct. >>>> >>>> Ha ha. >>>> >>>> Again, it seems that just automatically rerunning the test immediately >>>> after >>>> a human-manipulated run and setting the color based on that second run >>>> addresses all points on both sides, no? >>>> >>> >>> Except that sometimes we are debugging slow test and running it second >>> time automatically after "proceed" can be not appropriate. >>> We are talking about single test run. If user have any doubts about >>> result It is his responsibility to rerun the test. User knows what he is >>> doing when he debug and fix the test. No intelligence is required here. >>> >>> And anyway current fix just provides consistent behaviour to debugging >>> from explicit breakpoint/halt. In that case the result was always in sync >>> with debug session. >>> >>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>> >>>> >>> >> >> >> -- >> >> >> >> 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> >> > > -- 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

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Denis Kudriashov

2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > And just putting it back to gray? As "not run"? > We can implement any logic. Personally I need current behaviour. > > On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >>> Ben Coman wrote >>> > Or it could go to Amber, half-way between green & red to mean probably >>> > correct. >>> >>> Ha ha. >>> >>> Again, it seems that just automatically rerunning the test immediately >>> after >>> a human-manipulated run and setting the color based on that second run >>> addresses all points on both sides, no? >>> >> >> Except that sometimes we are debugging slow test and running it second >> time automatically after "proceed" can be not appropriate. >> We are talking about single test run. If user have any doubts about >> result It is his responsibility to rerun the test. User knows what he is >> doing when he debug and fix the test. No intelligence is required here. >> >> And anyway current fix just provides consistent behaviour to debugging >> from explicit breakpoint/halt. In that case the result was always in sync >> with debug session. >> >> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> > > > -- > > > > 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> >

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Guillermo Polito

And just putting it back to gray? As "not run"? On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Ben Coman wrote >> > Or it could go to Amber, half-way between green & red to mean probably >> > correct. >> >> Ha ha. >> >> Again, it seems that just automatically rerunning the test immediately >> after >> a human-manipulated run and setting the color based on that second run >> addresses all points on both sides, no? >> > > Except that sometimes we are debugging slow test and running it second > time automatically after "proceed" can be not appropriate. > We are talking about single test run. If user have any doubts about result > It is his responsibility to rerun the test. User knows what he is doing > when he debug and fix the test. No intelligence is required here. > > And anyway current fix just provides consistent behaviour to debugging > from explicit breakpoint/halt. In that case the result was always in sync > with debug session. > > >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > -- 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

Nov. 15, 2017