November 2017 - Pharo-users

Looking for small boards and tiny computers which can run Pharo
by Steven Costiou March 29, 2018

March 29, 2018

Hi, i am looking for: - small hardware, boards/computers, "embeddable" devices, etc. that can run Pharo (except Raspberry pi that i already know) - robots, flying drones or things alike with an open linux which can possibly run Pharo Could somebody points me to documentation or web sites where such things can be found ? Thanks, Steven.

8 10

Porting Transducers to Pharo
by Steffen MÃ¤rcker March 21, 2018

March 21, 2018

Hi, I am the developer of the library 'Transducers' for VisualWorks. It was formerly known as 'Reducers', but this name was a poor choice. I'd like to port it to Pharo, if there is any interest on your side. I hope to learn more about Pharo in this process, since I am mainly a VW guy. And most likely, I will come up with a bunch of questions. :-) Meanwhile, I'll cross-post the introduction from VWnc below. I'd be very happy to hear your optinions, questions and I hope we can start a fruitful discussion - even if there is not Pharo port yet. Best, Steffen Transducers are building blocks that encapsulate how to process elements of a data sequence independently of the underlying input and output source. # Overview ## Encapsulate Implementations of enumeration methods, such as #collect:, have the logic how to process a single element in common. However, that logic is reimplemented each and every time. Transducers make it explicit and facilitate re-use and coherent behavior. For example: - #collect: requires mapping: (aBlock1 map) - #select: requires filtering: (aBlock2 filter) ## Compose In practice, algorithms often require multiple processing steps, e.g., mapping only a filtered set of elements. Transducers are inherently composable, and hereby, allow to make the combination of steps explicit. Since transducers do not build intermediate collections, their composition is memory-efficient. For example: - (aBlock1 filter) * (aBlock2 map) "(1.) filter and (2.) map elements" ## Re-Use Transducers are decoupled from the input and output sources, and hence, they can be reused in different contexts. For example: - enumeration of collections - processing of streams - communicating via channels # Usage by Example We build a coin flipping experiment and count the occurrence of heads and tails. First, we associate random numbers with the sides of a coin. scale := [:x | (x * 2 + 1) floor] map. sides := #(heads tails) replace. Scale is a transducer that maps numbers x between 0 and 1 to 1 and 2. Sides is a transducer that replaces the numbers with heads an tails by lookup in an array. Next, we choose a number of samples. count := 1000 take. Count is a transducer that takes 1000 elements from a source. We keep track of the occurrences of heads an tails using a bag. collect := [:bag :c | bag add: c; yourself]. Collect is binary block (reducing function) that collects events in a bag. We assemble the experiment by transforming the block using the transducers. experiment := (scale * sides * count) transform: collect. From left to right we see the steps involved: scale, sides, count and collect. Transforming assembles these steps into a binary block (reducing function) we can use to run the experiment. samples := Random new reduce: experiment init: Bag new. Here, we use #reduce:init:, which is mostly similar to #inject:into:. To execute a transformation and a reduction together, we can use #transduce:reduce:init:. samples := Random new transduce: scale * sides * count reduce: collect init: Bag new. We can also express the experiment as data-flow using #<~. This enables us to build objects that can be re-used in other experiments. coin := sides <~ scale <~ Random new. flip := Bag <~ count. Coin is an eduction, i.e., it binds transducers to a source and understands #reduce:init: among others. Flip is a transformed reduction, i.e., it binds transducers to a reducing function and an initial value. By sending #<~, we draw further samples from flipping the coin. samples := flip <~ coin. This yields a new Bag with another 1000 samples. # Basic Concepts ## Reducing Functions A reducing function represents a single step in processing a data sequence. It takes an accumulated result and a value, and returns a new accumulated result. For example: collect := [:col :e | col add: e; yourself]. sum := #+. A reducing function can also be ternary, i.e., it takes an accumulated result, a key and a value. For example: collect := [:dic :k :v | dict at: k put: v; yourself]. Reducing functions may be equipped with an optional completing action. After finishing processing, it is invoked exactly once, e.g., to free resources. stream := [:str :e | str nextPut: each; yourself] completing: #close. absSum := #+ completing: #abs A reducing function can end processing early by signaling Reduced with a result. This mechanism also enables the treatment of infinite sources. nonNil := [:res :e | e ifNil: [Reduced signalWith: res] ifFalse: [res]]. The primary approach to process a data sequence is the reducing protocol with the messages #reduce:init: and #transduce:reduce:init: if transducers are involved. The behavior is similar to #inject:into: but in addition it takes care of: - handling binary and ternary reducing functions, - invoking the completing action after finishing, and - stopping the reduction if Reduced is signaled. The message #transduce:reduce:init: just combines the transformation and the reducing step. However, as reducing functions are step-wise in nature, an application may choose other means to process its data. ## Reducibles A data source is called reducible if it implements the reducing protocol. Default implementations are provided for collections and streams. Additionally, blocks without an argument are reducible, too. This allows to adapt to custom data sources without additional effort. For example: "XStreams adaptor" xstream := filename reading. reducible := [[xstream get] on: Incomplete do: [Reduced signal]]. "natural numbers" n := 0. reducible := [n := n+1]. ## Transducers A transducer is an object that transforms a reducing function into another. Transducers encapsulate common steps in processing data sequences, such as map, filter, concatenate, and flatten. A transducer transforms a reducing function into another via #transform: in order to add those steps. They can be composed using #* which yields a new transducer that does both transformations. Most transducers require an argument, typically blocks, symbols or numbers: square := Map function: #squared. take := Take number: 1000. To facilitate compact notation, the argument types implement corresponding methods: squareAndTake := #squared map * 1000 take. Transducers requiring no argument are singletons and can be accessed by their class name. flattenAndDedupe := Flatten * Dedupe. # Advanced Concepts ## Data flows Processing a sequence of data can often be regarded as a data flow. The operator #<~ allows define a flow from a data source through processing steps to a drain. For example: squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000). fileOut writeStream <~ #isSeparator filter <~ fileIn readStream. In both examples #<~ is only used to set up the data flow using reducing functions and transducers. In contrast to streams, transducers are completely independent from input and output sources. Hence, we have a clear separation of reading data, writing data and processing elements. - Sources know how to iterate over data with a reducing function, e.g., via #reduce:init:. - Drains know how to collect data using a reducing function. - Transducers know how to process single elements. ## Reductions A reduction binds an initial value or a block yielding an initial value to a reducing function. The idea is to define a ready-to-use process that can be applied in different contexts. Reducibles handle reductions via #reduce: and #transduce:reduce: For example: sum := #+ init: 0. sum1 := #(1 1 1) reduce: sum. sum2 := (1 to: 1000) transduce: #odd filter reduce: sum. asSet := [:set :e | set add: e; yourself] initializer: [Set new]. set1 := #(1 1 1) reduce: asSet. set2 := #(1 to: 1000) transduce: #odd filter reduce: asSet. By combining a transducer with a reduction, a process can be further modified. sumOdds := sum <~ #odd filter setOdds := asSet <~ #odd filter ## Eductions An eduction combines a reducible data sources with a transducer. The idea is to define a transformed (virtual) data source that needs not to be stored in memory. odds1 := #odd filter <~ #(1 2 3) readStream. odds2 := #odd filter <~ (1 to 1000). Depending on the underlying source, eductions can be processed once (streams, e.g., odds1) or multiple times (collections, e.g., odds2). Since no intermediate data is stored, transducers actions are lazy, i.e., they are invoked each time the eduction is processed. # Origins Transducers is based on the same-named Clojure library and its ideas. Please see: http://clojure.org/transducers

10 42

About validation
by StÃ©phane Ducasse March 11, 2018

March 11, 2018

Hi I read the chapter on validation of the mentoring course book of andres valloud. http://www.lulu.com/fr/fr/shop/andres-valloud/a-mentoring-course-on-smallta… And I love this extension of SUnit. I loved the idea when I saw it for the first time at Lugano (presentation of Leandro Caniglia). I encourage everybody to read it. Now does anybody implemented in Pharo the SUnit extension? I would like to play with it and eventually write a chapter on it for the next book. The idea is so good. Stef

2 1

Embedded PDF viewer?
by Manuel Leuenberger Feb. 6, 2018

Feb. 6, 2018

Hi, I want to view a PDF within Pharo. I found that Athens has a PDF canvas, but I have no idea how to use it. Is there a way to view a PDF within Pharo, so that I can scroll, zoom, click links etc. in the PDF? Cheers, Manuel

10 17

Usability issues with Calypso
by kmo Dec. 27, 2017

Dec. 27, 2017

I have been keen to use Calypso (I love the way it shows inherited methods) as my browser but I am finding some usability issues. It may be just me but some things I find off-putting. I don't really like the way that adding a new class is done by a new tab that appears now and then in the editing area. To my mind the Nautilus way of launching a dialog to create a class seems more natural - and opens the way in future for a class creation wizard - something that can't be done in a code window. If we have to do it in a code tab then it would be better if the tab remained there all the time - I don't like the way it appears and disappears. It takes a while to learn what to click to do this. Also, all class creation presumes a subclass of Object in Calypso. i miss the ability in Nautilus to select a class and immediately create a subclass of it. Am I missing something here? Is there a way? On the topic of my ignorance - what is a /project /in Calypso? How do you create one? And what does realize do? Also I think that the pop up menus could be subdivided into categories rather than present all the options in an unbroken list. And the order of options seems odd. To my mind/ senders /and /implementers /are two menu options that should always go together - not be separated by/ rename/ and /move to class side/ et cetera. Just my two cents. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

5 20

Fuel transfer from Pharo 1.4 to Pharo 6.1
by Andreas Brodbeck Dec. 22, 2017

Dec. 22, 2017

Hi all, I have a long running Seaside/Pharo application which still runs perfect on Pharo 1.4. I want to step into the future and migrate to the newest Pharo 6.1. The application's persistence is just in the image, so my plan is to use Fuel to transfer the objects from Pharo 1.4 to Pharo 6.1. My first attempt: --- Using Fuel version 1.9.4 on both VMs. --- Class TimeStamp was missing, so I created it. --- I use a Fuel-migration for the renaming of "MethodContext" into the new "Context" class. But now I am stuck with FLMethodChanged errors. My investigation shows that there are unequal values for the method Context>>bytecodesHash when comparing Pharo 1.4 with 6.1. (BTW: Pharo 5 gives same values like 6.1). So, basically Fuel can not materialize the instances because the bytecode hash of all methods have changed, comparing 1.4 to 6.1. My feeling says that this could be a major problem for my plans to migrate from Pharo 1.4 to 6.1. Is there a chance to still load those instances with Fuel into the new 6.1 Pharo? Thanks! Andreas -- Andreas Brodbeck www.mindclue.ch

7 19

I love the launcher!!!!
by Stephane Ducasse Dec. 12, 2017

Dec. 12, 2017

Hi I love the PharoLauncher. It helps me to manage my parallel development and projects. We should put a link on the Pharo web site because http://files.pharo.org/platform/launcher/ is arcane. Stef

10 19

P3 timeout
by Pierce Ng Dec. 12, 2017

Dec. 12, 2017

Hi Sven and all, I have a PostgreSQL database running in a resource-light Linux VM with ~4 million rows consisting of mostly text. My query executes regexp_matches() on the text and it runs noticeably slowly. I am encountering ConnectionTimedOut using P3 to run my query. PostgresV2 and Python's pg8000 do work though. I see that PostgresV2's PGConnection uses "Socket standardTimeout". I changed ZdcSimpleSocketStream class-side's #openConnectionToHostNamed:port: bottom part to add the same timeout because P3Client>>open calls it: ZdcSimpleSocketStream class>>openConnectionToHostNamed: hostName port: portNumber [...] ^ socketStream timeout: Socket standardTimeOut; "<== added this line" connectTo: hostIP port: portNumber; yourself Now my query returns instead of timing out. It does look like ZdcSimpleSocketStream's three class-side methods could use some refactoring love. Pierce

4 10

OSProcess lock image
by Hilaire Dec. 12, 2017

Dec. 12, 2017

Hello, On Pharo4, when I type the command: OSProcess waitForCommand: 'ls' it locks the image, I can get back control with [Alt]-. With the same image and VM, this command was previously working, even called from a Seaside component. Any idea? Thanks Hilaire -- Dr. Geo http://drgeo.eu

4 4

Using a TreePresenter
by Prof. Andrew P. Black Dec. 10, 2017

Dec. 10, 2017

I'm trying to use a (subclass of a) TreePresenter that is populated with FileReferences. I see that the current selection is, reasonably enough, a TreeNodePresenter, so I'm assuming that to set a selection programatically, I'm going to have to find the right TreeNodePresenter. So I've assumed a method allItemsDo: that I'm trying to write on my subclass of TreePresenter that will iterate through all of the TreeNodes and let me do stuff, such as looking at their #content to see if this is a node that I'm interested in. But I can't! The #roots method of TreePresenter doesn't give me the root TreeNodePresenters; it gives me the file references that they contain. How do I iterate over the TreeNodePresenters? Or am I going about this in entirely the wrong way? Andrew

2 1