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

Re: [Pharo-users] Commits Using Iceberg
by Guillermo Polito March 22, 2018

March 22, 2018

Hi Asbath, are you in 32 or 64 bits? We've seen problems in Pharo 6.1 64bits using iceberg while calling external libraries. On Thu, Mar 22, 2018 at 9:15 AM, Asbath via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Asbath <asamabiyalou(a)yahoo.com> > To: pharo-users(a)lists.pharo.org > Cc: > Bcc: > Date: Thu, 22 Mar 2018 09:15:14 +0100 > Subject: Commits Using Iceberg > Hi everybody, > > I am using Iceberg on Pharo 6. My OS is Ubuntu 16.04. > > When I try to commit my local changes on the remote branch, the Pharo > Image is closed, when I click on Commit and Push (after providing the > comment). Those commits are registered, but not published. > > I don't know what is the matter !? > > > Thanks, have a nice day > > > Asbath > > > > -- 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

2 1

Commits Using Iceberg
by Asbath March 22, 2018

March 22, 2018

Hi everybody, I am using Iceberg on Pharo 6. My OS is Ubuntu 16.04. When I try to commit my local changes on the remote branch, the Pharo Image is closed, when I click on Commit and Push (after providing the comment). Those commits are registered, but not published. I don't know what is the matter !? Thanks, have a nice day Asbath

1 0

Unable to execute example code from "The Spec UI Framework" Book
by dragoncity March 22, 2018

March 22, 2018

Hello, I'm just getting into Pharo, and am trying to do the example 'tutorial' UI programs in chapter 2 of The Spec UI Framework book. I have a special interest in end user GUI interfaces for programs. I enter the first example code as written and the methods are all accepted without errors. And yes, I did generate the accessors. However , on attempting to execute the code at the bottom of page 6 from the latest Spec UI Framework book, | ui | ui := CustomerSatisfaction newopenWithSpec. ui close. this error message appears, no UI image appears of course. "SubclassResponsibility:CustomerSatisfaction class had the subclass responsibility to implement #defaultSpec" ====== Not only don't I understand the message, but it implies I have to write something called #defaultSpec !, which is not mentioned in the tutorial. Any help appreciated, Yours, -- Cheers, Brett

7 9

Pharo sound with SDL Library
by Mariano Badoglio March 21, 2018

March 21, 2018

Hello! I need to use the Pharo Sound over Ubuntu platform, but I couldn't get it work. I tryied sending the parameter vm-sound-OSS and vm-sound-ALSA to the vm but I get no results. I am now trying to use the SDL Library. I could initialize the sound SDL_Init(SDL_INIT_AUDIO), very similar to initializing video, but when trying to use the SDL_LoadWAV, it needs a SDL_AudioSpec data type and I do not know how to do it. I tried to use an Structure as parameter but with no result, I couldn't found any similar example to follow. I will appreciate any help or tips on this. Thanks in advance. Best regards, Mariano.Â

3 6

How to model extension method in UML
by Jan BlizniÄenko March 21, 2018

March 21, 2018

Hello I have a question regarding UML modelling of Pharo extension method. If I have a class ClassA in package PackageA, and I have a package PackageB which contains extension method of ClassA (so there is a new method in ClassA with protocol "*PackageB"), how exactly to model this situation in UML class/package diagram? Thank you. Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

2 1

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

Re: [Pharo-users] Porting Transducers to Pharo
by ClÃ©ment Bera March 21, 2018

March 21, 2018

On Fri, Jun 2, 2017, 17:05 Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Dear all, > > thanks for the many suggestions. I didn't had time to test all > import/export ways yet. But for now, I can report on two: > > 1) NGFileOuter > Unfortunately It raised several MNUs in my image. I'll investigate them > later. > > 2) FileOut30 (VW Contributed) > I was able to file out the code except for the package definition. > Replacing {category: ''} in the class definitions with {package: > 'Transducers'} fixed that. However, methods that extend existing classes > did not end up in the Transducers package. Is there a similar easy change > to the file-out making that happen? Also I'd like to add the package > comment if that's possible. > > Most things appear to work as far as I can see. Two exceptions: > 1) Random is a subclass of Stream in VW and in Pharo it is not. Hence, > I'll have to copy some methods from Stream to Random. > 2) I used #beImmutable in VW but I couldn't yet figure out how to make > objects immutable in Pharo. > #beReadOnlyObject. Pharo 6.1 and onwards. #beWritable to revert. > However, until the tests are ported, I cannot guarantee. Porting the test > suite will be another beast, since I rely on the excellent mocking/stubbing > library DoubleAgents by Randy Coulman. I am not sure how I will handle > that. In general, I think it would be really worth the effort to be ported > to Pharo, too. DoubleAgents is pretty powerful and produces easy to read > and understand mocking/stubbing code. Personally, I prefer it clearly, > e.g., over Mocketry (no offence intended!). > > Attached you'll find the file-out that I loaded into Pharo. The issues > above are not addressed yet. However, the following example works: > > | scale sides count collect experiment random samples coin flip | > > scale := [:x | (x * 2 + 1) floor] map. > sides := #(heads tails) replace. > count := 1000 take. > > collect := [:bag :c | bag add: c; yourself]. > experiment := (scale * sides * count) transform: collect. > random := #(0.1 0.3 0.4 0.5 0.6 0.7 0.8 0.9). > > samples := random > > reduce: experiment > init: Bag new. > > samples := random > > transduce: scale * sides * count > reduce: collect > init: Bag new. > > coin := sides <~ scale <~ random. > > flip := Bag <~ count. > > samples := flip <~ coin. > > > Best, Steffen > > > > Am .06.2017, 08:16 Uhr, schrieb Stephane Ducasse <stepharo.self(a)gmail.com > >: > > There is a package for that NGFileOuter or something like that on cincom >> store. >> We used it for mobydic code. >> >> On Wed, May 31, 2017 at 6:35 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> >> wrote: >> >> If I remember correctly, there is a parcel in VisualWorks to export a file >>> out (Squeak format). >>> >>> @Milton, can you give a hand to Steffen? >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> On May 31, 2017, at 10:32 AM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> Thanks for the encouraging response! First question: Which is the >>> recommended (friction free) way to exchange code between VW and Pharo? >>> >>> Cheers! >>> Steffen >>> >>> Am .05.2017, 16:22 Uhr, schrieb Alexandre Bergel < >>> alexandre.bergel(a)me.com >>> >: >>> >>> I second Sven. This is very exciting! >>> >>> Let us know when you have something ready to be tested. >>> >>> Alexandre >>> >>> >>> >>> >>>

1 0

New Files in Pharo - Migration Guide, How To's and examples
by Guillermo Polito March 21, 2018

March 21, 2018

Hi all, I've put some minutes summarizing the new APIs provided by the combination of the new File implementation and the Zn encoders. They all basically follow the decorator pattern to stack different responsibilities such as buffering, encoding, line ending convertions. Please, do not hesitate to give your feedback. Guille 1. Basic Files By default files are binary. Not buffered. (File named: 'name') readStream. (File named: 'name') readStreamDo: [ :stream | ... ]. (File named: 'name') writeStream. (File named: 'name') writeStreamDo: [ :stream | ... ]. 2. Encoding To add encoding, wrap a stream with a corresponding ZnCharacterRead/WriteStream. "Reading" utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'. utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'. "Writing" utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'. utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf16'. 3. Buffering To add buffering, wrap a stream with a corresponding ZnBufferedRead/WriteStream. bufferedReadStream := ZnBufferedReadStream on: aStream. bufferedWriteStream := ZnBufferedWriteStream on: aStream. It is in general better to buffer the reading on the binary file and apply the encoding on the buffer in memory than the other way around. See [file := Smalltalk sourcesFile fullName. (File named: file) readStreamDo: [ :binaryFile | (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: 'utf8') upToEnd ]] timeToRun. "0:00:00:09.288" [file := Smalltalk sourcesFile fullName. (File named: file) readStreamDo: [ :binaryFile | (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding: 'utf8')) upToEnd ]] timeToRun. "0:00:00:14.189" 4. File System By default, file system files are buffered and utf8 encoded to keep backwards compatibility. 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ]. 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ]. FileStream also provides access to plain binary files using the #binaryRead/WriteStream messages. Binary streams are buffered by default also. 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... ]. 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ... ]. If you want a file with another encoding (to come in the PR https://github.com/pharo-project/pharo/pull/1134) you can specify it while obtaining the stream: 'name' asFileReference readStreamEncoded: 'utf16' do: [ :bufferedUtf16Stream | ... ]. 'name' asFileReference writeStreamEncoded: 'utf8' do: [ :bufferedUtf16Stream | ... ]. 5. Line Ending Conventions If you want to write files following a specific line ending convention, use the ZnNewLineWriterStream. This stream decorator will transform any line ending (cr, lf, crlf) into a defined line ending. By default it chooses the platform line ending convention. lineWriter := ZnNewLineWriterStream on: aStream. If you want to choose another line ending convention you can do: lineWriter forCr. lineWriter forLf. lineWriter forCrLf. lineWriter forPlatformLineEnding. -- 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

10 18

Re: [Pharo-users] Zinc URL and ASCII Encoding
by Sven Van Caekenberghe March 20, 2018

March 20, 2018

Hi Gareth, > On 19 Mar 2018, at 15:23, Gareth Cox <gareth(a)inspired.org> wrote: > > Hi Sven > > Is Zinc being overly fussy with encoding or is ASCII only URL strings a standard. > the following fails in a workspace/playground. > > 'http://www.yr.no/place/Mexico/Nuevo_LeÃ³n/Monterrey/forecast.xml' asZnUrl > > The url comes from the yr.no database (via api). It is vaild if you paste into a browser. > Let me know what you think > > Thanks > Gareth (I am replying with CC to the ML for future reference). When ZnUrl parses a string representation of a URL it is indeed strict. As per the spec this must be ASCII. Browsers typically allow a wider range of input. But of course, these URLs are supported, you just have to construct them differently. If you use the direct construction API, you can use full Unicode. ZnUrl new scheme: #http; host: 'www.yr.no'; addPathSegments: #('place' 'Mexico' 'Nuevo_LeÃ³n' 'Monterrey' 'forecast.xml'); yourself. You'll see that the external representation of your URL is actually the following, which is acceptable to the parser. 'http://www.yr.no/place/Mexico/Nuevo_Le%C3%B3n/Monterrey/forecast.xml' asUrl. BTW, I would do your request as follows (using XML Support) : ZnClient new systemPolicy; http; host: 'www.yr.no'; addPath: #('place' 'Mexico' 'Nuevo_LeÃ³n' 'Monterrey' 'forecast.xml'); accept: 'text/xml' asMIMEType; contentReader: [ :entity | XMLDOMParser parse: entity contents ]; get. In my Pharo 7 image, this gives me a nice coloured, fully parsed DOM: HTH, Sven

2 1

MiniScheme in Pharo
by Stephane Ducasse March 19, 2018

March 19, 2018

Hi I finally decided to release the booklet I wrote about implementing a minischeme in Pharo. I did not announce it yet because I would like to get feedback and fix what can be fixed. https://files.pharo.org/books-pdfs/booklet-AMiniSchemeInPharo/2018-03-17-Mi… Stef

4 6