January 2018 - Pharo-users - lists.pharo.org

GSoC 2018: Old Topics Must Be Removed

by Oleksandr Zaytsev

Hello! I have noticed that some of the projects in Pharo GSOC 2018 Ideas List <http://gsoc.pharo.org/> are copied from last year's list. I've asked people who have been assigned as mentors to these projects and they told me that they will not be mentoring them this year. I have created a pull request <https://github.com/pharo-project/pharo-project-proposals/pull/44> for removing two old projects that I found and discussed with mentors. But there's probably more. I think that the list of ideas has to be thoroughly reviewed and old projects must be removed from it before students start applying for them. Is there someone maintaining that list, who keeps track of all projects and knows which ones to remove? Oleks

Jan. 26, 2018

Re: [Pharo-users] Lengthy operations block UI

by Andrei Stebakov

Basically the test confirms that the long lasting scraping operation returns the expected result . As you suggested let me take a look at Zn On Jan 26, 2018 10:31, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > > > > On 26 Jan 2018, at 16:16, Andrei Stebakov <lispercat(a)gmail.com> wrote: > > > > How do you handle forked operations from TestCase point of view, when > the test expects a value to assert from an asynchronous operation? > > tests typically run sequential & synchronous, it is hard to work with them > otherwise (to debug them, to handle there failures). > > it is of course possible to write much more complex tests, doing all kind > of magic, but well, they are complex and require experience. > > many Zn test run http client against http servers, you could look there > for examples. > > what is your exact scenario or use case ? > > > On Jan 25, 2018 10:41, "Andrei Stebakov" <lispercat(a)gmail.com> wrote: > > Thanks, Sven, got it > > > > On Jan 25, 2018 10:36, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > > Hi Andrei, > > > > > On 25 Jan 2018, at 16:26, Andrei Stebakov <lispercat(a)gmail.com> wrote: > > > > > > I have written some code that has a deep nested loop of calling > ZnClient>>get. > > > In the loop I also execute Transcript>>show but I can only see the > transcript output after a few seconds when the loop is finished. During all > that time while the loop is busy the UI is also unresponsive. > > > Is there a way to execute code in some sort of asynchronous way? > > > > The problem is not specific to using ZnClient, it is with every loop you > execute in the UI thread: the Transcript output is not updated (as it is > the UI thread itself that has to do the drawing). > > > > For example, try > > > > 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ]. > > > > The solution is to run you long running code in another thread, like this > > > > [ 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ] ] fork. > > > > HTH, > > > > Sven > > >

Jan. 26, 2018

Re: [Pharo-users] Lengthy operations block UI

by Sven Van Caekenberghe

> On 26 Jan 2018, at 16:16, Andrei Stebakov <lispercat(a)gmail.com> wrote: > > How do you handle forked operations from TestCase point of view, when the test expects a value to assert from an asynchronous operation? tests typically run sequential & synchronous, it is hard to work with them otherwise (to debug them, to handle there failures). it is of course possible to write much more complex tests, doing all kind of magic, but well, they are complex and require experience. many Zn test run http client against http servers, you could look there for examples. what is your exact scenario or use case ? > On Jan 25, 2018 10:41, "Andrei Stebakov" <lispercat(a)gmail.com> wrote: > Thanks, Sven, got it > > On Jan 25, 2018 10:36, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > Hi Andrei, > > > On 25 Jan 2018, at 16:26, Andrei Stebakov <lispercat(a)gmail.com> wrote: > > > > I have written some code that has a deep nested loop of calling ZnClient>>get. > > In the loop I also execute Transcript>>show but I can only see the transcript output after a few seconds when the loop is finished. During all that time while the loop is busy the UI is also unresponsive. > > Is there a way to execute code in some sort of asynchronous way? > > The problem is not specific to using ZnClient, it is with every loop you execute in the UI thread: the Transcript output is not updated (as it is the UI thread itself that has to do the drawing). > > For example, try > > 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ]. > > The solution is to run you long running code in another thread, like this > > [ 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ] ] fork. > > HTH, > > Sven

Jan. 26, 2018

Re: [Pharo-users] Lengthy operations block UI

by Andrei Stebakov

How do you handle forked operations from TestCase point of view, when the test expects a value to assert from an asynchronous operation? On Jan 25, 2018 10:41, "Andrei Stebakov" <lispercat(a)gmail.com> wrote: > Thanks, Sven, got it > > On Jan 25, 2018 10:36, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > >> Hi Andrei, >> >> > On 25 Jan 2018, at 16:26, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> > >> > I have written some code that has a deep nested loop of calling >> ZnClient>>get. >> > In the loop I also execute Transcript>>show but I can only see the >> transcript output after a few seconds when the loop is finished. During all >> that time while the loop is busy the UI is also unresponsive. >> > Is there a way to execute code in some sort of asynchronous way? >> >> The problem is not specific to using ZnClient, it is with every loop you >> execute in the UI thread: the Transcript output is not updated (as it is >> the UI thread itself that has to do the drawing). >> >> For example, try >> >> 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ]. >> >> The solution is to run you long running code in another thread, like this >> >> [ 1 to: 10 do: [ :i | Transcript crShow: i. 5 seconds wait ] ] fork. >> >> HTH, >> >> Sven >> >

Jan. 26, 2018

Re: [Pharo-users] looking for another iterator :)

by Steffen MÃ¤rcker

Hi! No stress is good news! > - what is the API in terms of vocabulary (ie drop the same as reject) These are the operations implemented so far. |= means "satisfies", i.e., evaluate to true. Drop drop first n elements DropWhile drop first elements |= a block Filter* pick only elements |= a block Keep* only use elements ~= nil Map* map each element MapKeys* map each element an use as key Partition split after n elements PartitionBy split after elements |= a block RandomSample* pick elements with probability p Reductions intermediate results of reduce Remove* = Filter not Replace* replace elements by LUT Cat* concatenate sequences Dedupe remove consecutive duplicates Flatten* flatten nested sequence Take pick first n elements TakeNth pick every n-th element TakeWhile pick first elements |= a block Tee UNIX tee, concurrent evaluation Note, * means that the operation is parallelizable. As the operations are independent of the sequence class, the apply naturally to all kinds of sources, like collections, streams, channels and so on. > - can we reexpress some of our iterators? Most of them. For example, generic for all collections: collect: aBlock ^self class <~ aBlock map <~ self reject: aBlock ^self class <~ ablock remove <~ self select: aBlock ^self class <~ aBlock filter <~ self As said before, names are not fixed yet and there is a more classical API on top available, too: collect: aBlock ^(self transduce map: aBlock) into: self class > - what is the cost? Very little. In detail: 1) Upfront there is the constant cost of instantiating the tranducers. 2) The linear cost of evaluating a nested block for each element. This is likely to be optimized by the JIT, as the structure is very regular. I only did some micro-benchmarks which showed little to none impact on performance so far. Best, Steffen

Jan. 26, 2018

Re: [Pharo-users] looking for another iterator :)

by Evan Donahue

It is also worth mentioning that there is now also the Cons library available through the Pharo6 catalog browser. Cons is a lazy linked list that can be used like a normal linked list, but can also be used as an iterator over streams or infinite-sequence-generating blocks, using the usual Pharo collections API. myStream := (1 to: 100) readStream. (myStream asCons take: 5) do: [ ... ]. Due to the laziness, Cons, like Clojure's transducers, doesn't build intermediate representations, so things like #selectThenCollect: aren't necessary. (myList select: sBlock) collect: cBlock just creates an iterator and never actually creates the whole list, although you can still treat it like a list with #first, #allButRest, etc. The code is stable and in use in several of my projects. Evan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 26, 2018

Re: [Pharo-users] looking for another iterator :)

by Richard O'Keefe

I thought about that for my own Smalltalk, but then realised that I didn't know whether #upTo:timesSelect: was bounding the number of elements *considered* or the number of elements in the *result*, and I could argue either way. Arguably the cleanest way would be to have something like (LimitedEnumerableAdapter on: collection limit: anInteger) do: aBlock select: aBlock collect: aBlock ... *any* existing or new collection method. On 22 January 2018 at 11:46, James Foster <Smalltalk(a)jgfoster.net> wrote: > Since âatMax:â doesnât seem as clear to me, Iâd prefer âupToMax:â or > âwithMax:â or (especially) the following: > > upTo: anInteger timesDo: aBlock > upTo: anInteger timesSelect: aBlock > upTo: anInteger timesCollect: aBlock > > James Foster > > > On Jan 21, 2018, at 8:56 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > I thought about something like that... > > > > SequenceableCollection >> atMax: numberOfItems do: aBlock > > "Execute the iteration with at the maximum numberOfItems. If the > > receiver contains less than numberOfItems iterate them all." > > 1 to: (numberOfItems min: self size) do: [:index | aBlock value: > > (self at: index)] > > > > This is an abstraction that we need to treat some samples. > > > > Stef > > > > On Sun, Jan 21, 2018 at 5:47 PM, Stephane Ducasse > > <stepharo.self(a)gmail.com> wrote: > >> Hi Ben and Clement > >> > >> I have a collection (a dictionary in my case) and I want to get > >> maximum 5 bindings out of it and iterate on them. > >> I want keysAndValuesDo: or do: but only up to 5 elements. > >> > >> aDict atMax: 5 do: [:each | ] > >> > >> So I learned from:to:do: > >> > >> aCollection atMax: 5 do: [:each | ] > >> > >> Does it make sense? > >> > >> Stef > >> > >> On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >>> I don't think we do. Do you need it on SequenceableCollection or > >>> HashedCollection too ? > >>> > >>> Recently I was trying to iterate over the first N elements of a > collection > >>> and since there was no #first:do: I used #from:to:do:. I guess you > could use > >>> that too: > >>> > >>> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock > >>> > >>> Which guarantees you iterate at max over 1000 elements. But that API is > >>> SequenceableCollection specific. > >>> > >>> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> > wrote: > >>>> > >>>> On 21 January 2018 at 18:36, Stephane Ducasse < > stepharo.self(a)gmail.com> > >>>> wrote: > >>>>> Hi > >>>>> > >>>>> I would like to iterate at max on a certain amount of elements in a > >>>>> collection. > >>>>> And I was wondering if we have such iterator. > >>>> > >>>> I'm not clear what functionality your asking for. Could you present > >>>> it as code & result if you assumed the iterator you want was > >>>> available? > >>>> > >>>> cheers -ben > >>>> > >>> > >>> > >>> > >>> -- > >>> ClÃ©ment BÃ©ra > >>> Pharo consortium engineer > >>> https://clementbera.wordpress.com/ > >>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > >

Jan. 26, 2018

Re: [Pharo-users] looking for another iterator :)

by Richard O'Keefe

My own Smalltalk has these: Enumerable methods for: 'enumerating' limit: n do: aBlock "Pass elements of the receiver to aBlock one at a time, as for #do:, but stop after n elements. n must be a non-negative SmallInteger. Which elements you get is for the receiver to decide." |count| n < 1 ifTrue: [ n = 0 ifTrue: [^self]ifFalse: [self pvtCountError: n]]. count := 0. self do: [:each | aBlock value: each. (count := count + 1) < n ifFalse: [^self]]. AbstractKeyedCollection methods for: 'enumerating' limit: n keysAndValuesDo: aBlock "Pass keys and corresponding values of the receiver to aBlock one at a time, as for #keysAndValuesDo:, but stop after n elements. See #limit:do:." |count| n < 1 ifTrue: [ n = 0 ifTrue: [^self]ifFalse: [self pvtCountError: n]]. count := 0. self keysAndValuesDo: [:key :value | aBlock value: key value: value. (count := count + 1) < n ifFalse: [^self]]. Enumerable is the superclass of Collection; it doesn't cover streams but does cover 2- and 3-dimensional arrays. AbstractKeyedCollection covers both dictionaries and sequences. Since they only depend on #do: and #keysAndValuesDo: respectively, they should fit nicely into some sort of Trait(s). I gave a great deal of thought to the names, and decided on "limit" since it is already in use in a similar sense in things like LimitedOutputStream or #printStringLimitedTo:. I did consider #do:limitedTo: and #keysAndValuesDo:limitedTo: which would be more consistent with #streamContents:limitedTo:, but "heavy" things like blocks really work better at the end.

Jan. 26, 2018

Re: [Pharo-users] How to declare a do:[] loop for a matrix to read and acces its elements?

by Richard O'Keefe

Sorry about the late reply, but I've been away on holiday. You wrote "Im not sure is the gameworld should grow inifitly. In the ruleset on wikipedia there is a fixed board size. The smallest one is 3*3 but I could implement is as one possible size to select from." It's not your decision. Conway's Life simply *is* defined for an infinite world. Without that, it wouldn't be Turing-universal, as it is. The first sentence in the Rules section begins "The universe of the Game of Life is an infinite two-dimensional orthogonal <https://en.wikipedia.org/wiki/Orthogonal> grid". The ruleset on the Wikipedia page does NOT have a fixed size. The examples are shown just big enough to contain all the live cells, but that is another matter. There are four things you can do when emulating a game on a grid: (1) STOP when you hit the edge, deliberately or by crashing. (2) ERR by pretending everything outside is dead. The program does not stop, it just stops giving right answers. (3) REDEFINE the world to be a toroidal space instead of an infinite one. Again, this changes the rules enough to count as a different game. (4) GROW the world. Allocate a new bigger world and copy the old one across. But the best way to deal with limitations is to avoid building them into the program in the first place. It's a bit like concurrency. It took a while before I realised that "how do I add concurrency to my programs" was the wrong question and that I should have been asking "how do I learn to stop adding sequentiality to my programs?"

Jan. 26, 2018

Re: [Pharo-users] Voyage and Instance Mode

by Esteban Lorenzano

> On 25 Jan 2018, at 23:24, Dominique Dartois <dom(a)dartois.org> wrote: > > Thanks Esteban. > I was fooled by the doc : "In instance mode, the first argument is always the repository on which to performed the operation"... > Well, not really, but the object to store. yeah, it should say: the receiver. > > Regards > > 2018-01-25 23:07 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > > > On 25 Jan 2018, at 23:03, Dominique Dartois <dom(a)dartois.org <mailto:dom@dartois.org>> wrote: > > > > Hello all. > > > > I'am learning to use Voyage by trying the examples in the Voyage doc (in the Enterprise Pharo book). > > I read "By default, Voyage works in instance mode". > > If I run the example in instance mode, I get an error via the debugger. > > > > |repo anAssociation| > > repo := VOMemoryRepository new. > > anAssociation := #answer -> 42. > > anAssociation save: repo. > > repo save: anAssociation :) > > cheers! > Esteban > > > ==> "Instance of Association did not understand #save:" > > > > What am I doing wrong? > > > > -- > > Dominique > > > > > > -- > Dominique

Jan. 25, 2018