- Pharo-users - lists.pharo.org

Re: [Pharo-users] Connection Timed Out

by Ben Coman

On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > I have a Teapot application running under Linux and nginx. From time to > time, I get the following error: *ConnectionTimedOut: Data receive timed > out.* > > Otherwise, the Teapot application works fine, even with this error message. > > Can anyone tell me what or where it's timing out, and how can I change the > timeout value? > I'm not familiar with Teapot, but a screen snapshot might help. Hopefully someone else has some ideas. cheers -ben

Aug. 28, 2019

Connection Timed Out

by Richard Kenneth Eng

I have a Teapot application running under Linux and nginx. From time to time, I get the following error: *ConnectionTimedOut: Data receive timed out.* Otherwise, the Teapot application works fine, even with this error message. Can anyone tell me what or where it's timing out, and how can I change the timeout value? Thanks.

Aug. 27, 2019

Re: [Pharo-users] [ANN] Iterators

by Julien

> Le 24 aoÃ»t 2019 Ã 09:29, Steffen MÃ¤rcker <merkste(a)web.de> a Ã©crit : > > Hi Julien, Hello Steffen, > > nice work! Could you please tell how your approach is related to > transducers from the user perspective and technically? > (https://github.com/Pharophile/Transducers) It is quite similar, except that I actually started it the other way around: - First I wanted objects that can iterate on data structure (or any object) - Second I wanted object to eventually provide multiple iterators in order to walk them in multiple ways - Third I came with the IteratorWithCollectionAPI decorator which implements #select:, #collect: and so one in order to avoid re-implementing these methods on objects wrapping a collection - Since IteratorWithCollectionAPI is a decorator, I came up with the idea to push further the composition feature and at this point, I get Iterators to be similar to Transducer The original idea of Iterators can be summarised as: myObjectThatShouldImplementCollectionButIsNotACollection iterator collect: #foo. myObjectThatShouldImplementCollectionButIsNotACollection iterator do: #foo. myObjectThatShouldImplementCollectionButIsNotACollection iterator doWithIndex: #foo. â¦ Technically I donât know what are the similarities as I did not dig in Transducers implementation. >From the DSL design point of view, I wanted that the composition through binary messages keeps the data flow to go from top left to down right when you read the code. This gave me the idea to mimic shell language for stream manipulation. Hope it answers your questions. Cheers, Julien

Aug. 25, 2019

Re: [Pharo-users] Putting checkboxes in ListPresenter

by Richard Sargent

Thank you, Renaud, for explaining that. I am so glad to see that Pharo has addressed this and made it so simple. I've seen too many UIs that fail on this kind of thing. Kudos to those people who created this. You nailed it! On Sat, Aug 24, 2019, 18:31 Renaud de Villemeur <renaud.devillemeur(a)free.fr> wrote: > Hi Steve. > > This is not at all a naive question. This is partly showned in the advance > part of spec, and as it said: "ListModel can show more than just text, it > can also visualize any kind of widget." > > Here is how you could do a static list of checkBox: > In your initializeWidget method, create your checkbox: > > item1 := self newCheckBox label: 'label1'; help: 'help1'; yourself. > item2 := self newCheckBox label: 'label2; help: 'help2'; yourself. > item3 := self newCheckBox label: 'label3'; help: 'help3'; yourself. > > You can then create and display your list: > > projectList := (self instantiate: ListPresenter) > displayBlock: [ :x | x buildWithSpec ]; > items: {item1 . item2 . item3}; > yourself. > > > And your defaultSpec can be as simple as: > > defaultSpec [ > ^ SpecLayout composed > add: #projectList; > yourself > ] > > Hope this helps. > Renaud > > > Le sam. 24 aoÃ»t 2019 Ã 14:53, Steve Quezadas <steveeq1(a)gmail.com> a > Ã©crit : > >> Guys, >> >> I am learning this new "spec" thing. I created a simple Spec "list" >> object with the following code: >> arbitraryList := ListPresenter new. >> arbitraryList >> items: #('one' 'two' 'three' 'four. . .'); >> title: 'Arbitrary list'. >> arbitraryList openWithSpec. >> >> Which creates a simple list like follows: >> https://steverstuff.s3.amazonaws.com/arbitrary_list.png >> >> Is there any way to make a SpecPresenter object with an arbitrary list of >> checkboxes? Kind of like a check-off list? >> >> What is the best way of doing this? Should I put checkbox objects in the >> "items:" selector? Or is there another way to do it? >> >> Please forgive the naive question. >> >

Aug. 25, 2019

Re: [Pharo-users] [ANN] Iterators

by Richard O'Keefe

Distinguishing between "pull-based" and "push-based" streams in Smalltalk makes no sense, because do: aBlock [self atEnd] whileFalse: [aBlock value: self next]. is in the same <gettableStream> protocol in the ANSI standard as #atEnd and #next, and in most Smalltalk systems it is in Stream. There should never be anything that has #atEnd and #next that doesn't have #do:. In some Smalltalk systems, Stream and Collection both inherit from a common superclass. In GNU Smalltalk, it's called Iterable, and provides, amongst other things stream1 , stream2 stream allSatisfy: filterBlock stream anySatisfy: filterBlock stream collect: transformBlock stream count: filterBlock stream detect: filterBlock stream detect: filterBlock ifNone: exceptionBlock stream do: actionBlock stream do: actionBlock separatedBy: separatorBlock stream fold: combinerBlock stream inject: initial into: combinerBlock stream noneSatisfy: filterBlock stream reject: filterBlock stream select: filterBlock My Smalltalk library does not do that, but it does have an Enumerable class that's somewhat similar (the distinction is that multiple traversal of a Collection must work, but only single traversal of an Enumerable is required), so readStream asEnumerable reject: filterBlock This makes about 257 Enumerable methods available. Combinators are good, but they should fit in with existing naming conventions. *Arbitrary* overloadings are a bad idea. The pipe "|" allows one to chain iterators - The ">" allows one to create a new collection with data transformed through chained iterators - The ">>" allows one to fill an existing collection with data transformed through chained iterators The vertical bar is used in Smalltalk for "or". It would make sense to have MonadicBlock methods for: 'combinators' | other ^[:x | (self value: x) | (other value: x)] and so on. Smalltalk already has a selector that means "concatenation", namely #, so stream1 , stream2 as in GNU Smalltalk would not be too confusing. Similarly, ">" means "greater than", and it would be deeply confusing to use it for some sort of data construction. We would expect stream1 > stream2 iff the future values of stream1 (as a sequence) are lexicographically greater than the future values of stream2 (as a sequence). Or you could argue for "the relative order of two streams is the relative order of their positions if the have the same underlying Collection or file system object, otherwise undefined".

Aug. 25, 2019

Re: [Pharo-users] Putting checkboxes in ListPresenter

by Renaud de Villemeur

Hi Steve. This is not at all a naive question. This is partly showned in the advance part of spec, and as it said: "ListModel can show more than just text, it can also visualize any kind of widget." Here is how you could do a static list of checkBox: In your initializeWidget method, create your checkbox: item1 := self newCheckBox label: 'label1'; help: 'help1'; yourself. item2 := self newCheckBox label: 'label2; help: 'help2'; yourself. item3 := self newCheckBox label: 'label3'; help: 'help3'; yourself. You can then create and display your list: projectList := (self instantiate: ListPresenter) displayBlock: [ :x | x buildWithSpec ]; items: {item1 . item2 . item3}; yourself. And your defaultSpec can be as simple as: defaultSpec [ ^ SpecLayout composed add: #projectList; yourself ] Hope this helps. Renaud Le sam. 24 aoÃ»t 2019 Ã 14:53, Steve Quezadas <steveeq1(a)gmail.com> a Ã©crit : > Guys, > > I am learning this new "spec" thing. I created a simple Spec "list" object > with the following code: > arbitraryList := ListPresenter new. > arbitraryList > items: #('one' 'two' 'three' 'four. . .'); > title: 'Arbitrary list'. > arbitraryList openWithSpec. > > Which creates a simple list like follows: > https://steverstuff.s3.amazonaws.com/arbitrary_list.png > > Is there any way to make a SpecPresenter object with an arbitrary list of > checkboxes? Kind of like a check-off list? > > What is the best way of doing this? Should I put checkbox objects in the > "items:" selector? Or is there another way to do it? > > Please forgive the naive question. >

Aug. 25, 2019

Putting checkboxes in ListPresenter

by Steve Quezadas

Guys, I am learning this new "spec" thing. I created a simple Spec "list" object with the following code: arbitraryList := ListPresenter new. arbitraryList items: #('one' 'two' 'three' 'four. . .'); title: 'Arbitrary list'. arbitraryList openWithSpec. Which creates a simple list like follows: https://steverstuff.s3.amazonaws.com/arbitrary_list.png Is there any way to make a SpecPresenter object with an arbitrary list of checkboxes? Kind of like a check-off list? What is the best way of doing this? Should I put checkbox objects in the "items:" selector? Or is there another way to do it? Please forgive the naive question.

Aug. 24, 2019

Re: [Pharo-users] [ANN] Iterators

by Steffen MÃ¤rcker

Hi Julien, nice work! Could you please tell how your approach is related to transducers from the user perspective and technically? (https://github.com/Pharophile/Transducers) Your example suggests that the API is quite similar to the data flow API of transducers. Let me show your example using transducers. > result := (#+ init: 0) <~ [:x | x * 2] map <~ #(1 2 3). > OrderedCollection with: result. Or the more classical way: > result := #(1, 2, 3) > transduce: [:x | x * 2] map > reduce: #+ > init: 0. > OrderedCollection with: result. Best regards, Steffen

Aug. 24, 2019

Re: [Pharo-users] Finding replacements for deprecated functions

by Steve Quezadas

Ok, so with, for example, "SpecColumnLayout", how would I find the new method selector to use? On Mon, Aug 19, 2019 at 11:34 AM Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > > On Mon 19 Aug 2019 at 20:30, Steve Quezadas <steveeq1(a)gmail.com> wrote: > >> I am experimenting with smalltalk. Sometimes a function gets >> deprecated and is crossed out. Is there a "smalltalk way" of finding >> the equivalent replacement function? >> > Hello, > > Most of the time the deprecation explains what is the new way directly. > If itâs a change in the API with an equivalent method, it will be the one > called in the deprecated method that should now be called. > > For more complex cases, if you donât know the equivalent I guess the > easiest way is to ask the community on this ML. > -- > Cyril Ferlicot > https://ferlicot.fr >

Aug. 24, 2019

Re: [Pharo-users] [ANN] Iterators

by Herby VojÄÃk

On 23. 8. 2019 19:23, Herby VojÄÃk wrote:> On 23. 8. 2019 16:14, Julien wrote: >> Hello, >> >> I wanted to have an iterator framework for Pharo for a long time. >> >> So I started building it step by step and today I think that, while it >> still requires more documentation, it is ready to be announced and >> used by others. >> >> I present you Iterators : https://github.com/juliendelplanque/Iterators >> >> The idea is that, as described by the iterator design pattern, any >> object that needs to be walked provides one or many iterators. >> >> In the library, #iterator method is the convention to get the default >> iterator of any object (if it has one). >> >> Iterators provides a DSL to deal with iterators combination. >> >> It is inspired from shellâs streams manipulation syntax: >> >> - The pipe "|" allows one to chain iterators >> - The ">" allows one to create a new collection with data transformed >> through chained iterators >> - The ">>" allows one to fill an existing collection with data >> transformed through chained iterators >> For example, one can write: >> >> iterator := #(1 2 3) iterator. >> iterator >> | [ :x | x * 2 ] collectIt >> | [ :x :y | x + y ] reduceIt >> > Array "#(12)" > > Isn't this something readStream should provide? > > str := #(1 2 3) readStream. > str > | [ :x | x * 2 ] collectIt > | [ :x :y | x + y ] reduceIt > > Array "#(12)" > > It is an object from which you take the front element, one at a time. > > Why have something very similar with different name? > > Herby Now that I think about it, the problem may be a nomenclature. This is my understanding, fix me if I am mistaken: There are pull-based and push-based sequences out there. In Smalltalk it can be said a sequence is pull-based if it has #next and #atEnd; it is push-based if it has #do:. AFAICT the tools to read pull-based sequence is called an iterator, and it can have transformations like filter, map etc., sometimes called "ix". The approach to transform push-based sequence (called observable) is called reactive programming ("rx"). It seems you create rx-like library, but called the object iterator. Maybe the set of operations you provide should be define for both push-based and pull-based sequences, and called names that conform to common canon. Herby

Aug. 23, 2019