July 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] P7 regression

by Sven Van Caekenberghe

If you have a character read or write stream, you can use #wrappedStream to access the underlying binary stream, should you need to do that. > On 25 Jul 2019, at 20:31, Hilaire <hilaire(a)drgeo.eu> wrote: > > Thanks for the tips. It is definitely a left over from porting DrGeo to > P7 from P4/5/6 (not sure) > > But it can't really work as put:into: is used to write both sktech > content (XML file) and its PNG preview. > > At some point in Pharo history both UTF8 and bitmap were using binary > stream. > > Likely a putBinary:into: is needed too. > > -- > Dr. Geo > http://drgeo.eu > > >

July 25, 2019

Re: [Pharo-users] P7 regression

by Hilaire

Thanks for the tips. It is definitely a left over from porting DrGeo to P7 from P4/5/6 (not sure) But it can't really work as put:into: is used to write both sktech content (XML file) and its PNG preview. At some point in Pharo history both UTF8 and bitmap were using binary stream. Likely a putBinary:into: is needed too. -- Dr. Geo http://drgeo.eu

July 25, 2019

Re: [Pharo-users] Personal Programming

by CÃ©drick BÃ©ler

Me too ! And on the huge esug discussion points to have ^^ Cheers, Cedrick > Le 25 juil. 2019 Ã 13:09, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > Looks very interesting! I will read it (it arrives just in time to be part of the holiday reading pileâ¦) > > Marcus > >> On 25 Jul 2019, at 11:29, Trygve <trygver(a)ifi.uio.no> wrote: >> >> Dear all, >> The final draft of my magnum opus about Personal Programming is now ready for review: >> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf >> >> The article's main theme is Personal Programming for everybody with Loke, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program. >> >> The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment. >> >> I will appreciate your possible comments before Aug. 31. >> Enjoy >> --Trygve >> >> The article's 43 pages has several high points, I have included one of them here: >> ----------- begin extract ------------------ >> C.7.We need a paradigm shift >> >> The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next. >> >> It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them. >> >> It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements. >> >> Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal. >> >> The three paradigms of computing >> <pbeopicbehdhbfmc.png> >> It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article. >> >> The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric. >> >> ----------- end extract ------------------ >> >> >> >

July 25, 2019

Re: [Pharo-users] OrderedCollection as an instance variable

by Herby VojÄÃk

On 25. 7. 2019 4:27, Richard O'Keefe wrote: > Comment 2. > ?? This is a poor design.?? As it is, any object can replace the tracks > of an artist > ?? with *anything*.?? And even without doing that, any object can add and > remove > ?? items to an artist's tracks, even if the added items are not Tracks. > ?? There are a number of OO design principles, notably the Law of > Demeter and > ?? of course the GRASP patterns, which basically say "never mutate another > ?? object's parts, ask IT to do the mutation." As outlined nicely in this classic: https://alanknightsblog.blogspot.com/2011/10/principles-of-oo-design-or-eve….

July 25, 2019

Re: [Pharo-users] [Seaside] Save the date: October 22nd in Ghent for a Smalltalk WebCamp

by Esteban Maringolo

Hi, I look forward to meet many of you and put some real faces to the names :) Regards, Esteban A. Maringolo On Wed, Jul 24, 2019 at 2:23 PM Johan Brichau <johan(a)inceptive.be> wrote: > > Hi Seaside users, > > We are organising a Smalltalk WebCamp day in the Yesplan offices in Ghent on October 22nd. > > The idea originated in the Seaside channel of the Pharo discord group. However, itâs not supposed to be Seaside only. All Smalltalkers doing web development, possibly involving other technologies on top of Smalltalk, are encouraged to join. Letâs meet and exchange ideas. The topics are to be determined, following the idea of an unconference [1], except that, for practical reasons, we will ask you to confirm your attendance beforehand. > > More info to follow asap. > > Save the date and respond already to the group if you are interested to attend. > > Cheers > Johan > > [1] https://en.wikipedia.org/wiki/Unconference > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

July 25, 2019

Re: [Pharo-users] Personal Programming

by Marcus Denker

Looks very interesting! I will read it (it arrives just in time to be part of the holiday reading pileâ¦) Marcus > On 25 Jul 2019, at 11:29, Trygve <trygver(a)ifi.uio.no> wrote: > > Dear all, > The final draft of my magnum opus about Personal Programming is now ready for review: > http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf <http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf> > > The article's main theme is Personal Programming for everybody with Loke, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program. > > The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment. > > I will appreciate your possible comments before Aug. 31. > Enjoy > --Trygve > > The article's 43 pages has several high points, I have included one of them here: > ----------- begin extract ------------------ > C.7.We need a paradigm shift > > The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next. > > It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them. > > It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements. > > Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal. > > The three paradigms of computing > <pbeopicbehdhbfmc.png> > It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article. > > The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric. > > ----------- end extract ------------------ > > >

July 25, 2019

Re: [Pharo-users] OrderedCollection as an instance variable

by Herby VojÄÃk

On 24. 7. 2019 17:30, sergio ruiz wrote: > hmm??? > > maybe this is cleaner.. > > tracks > tracks ifNil: [ self tracks: OrderedCollection new ]. > ^ tracks IMO, return ifNil: value is an understood and used idiom, so I'd say ^ tracks ifNil: [ tracks := ... ] is the most clean way. Maybe look at sender of ifNil: and see for yourself which is the most idiomatic way to do lazy getter in the current image (there will be lots of these usages there). Herby >> >> because your #tracks: returns self, not the collection value > > ---- > peace, > sergio > photographer, journalist,??visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

July 25, 2019

Personal Programming

by Trygve

Dear all, The final draft of my magnum opus about Personal Programming is now ready for review: http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf The article's main theme is Personal Programming for everybody with /Loke/, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program. The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment. I will appreciate your possible comments before Aug. 31. Enjoy --Trygve The article's 43 pages has several high points, I have included one of them here: ----------- begin extract ------------------ C.7.We need a paradigm shift The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next. It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them. It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements. Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal. /The three paradigms of computing // /// It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article. The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric. ----------- end extract ------------------

July 25, 2019

Re: [Pharo-users] OrderedCollection as an instance variable

by Richard O'Keefe

Comment 1. You probably meant to write tracks: aCollection ^tracks := aCollection Comment 2. This is a poor design. As it is, any object can replace the tracks of an artist with *anything*. And even without doing that, any object can add and remove items to an artist's tracks, even if the added items are not Tracks. There are a number of OO design principles, notably the Law of Demeter and of course the GRASP patterns, which basically say "never mutate another object's parts, ask IT to do the mutation." I have come to regard the self-encapsulation "pattern" as an anti-pattern. This is Smalltalk heresy, admittedly, but it doesn't so much break (real) encapsulation as set it on fire, defenestrate it, and urinate on the smouldering remains. So this is the way I'd do it. Object subclass: #Artist instanceVariableNames: 'tracks' methods for: 'initialising' initialize tracks := OrderedCollection new. ^self methods for: 'checking' invariant ^(tracks isMemberOf: OrderedCollection) and: [ tracks allSatisfy: [:each | each isKindOf: Track]] methods for: 'accessing tracks' addTrack: aTrack. tracks add: aTrack. ^track tracksDo: doBlock tracks do: doBlock with no way for outside code to accesss 'tracks' directly. On Thu, 25 Jul 2019 at 02:47, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > I'm implementing an instance variable as an OrderedCollection, and am > doing something idiotic. > > I have an Artist class. > > An Artist can have many tracks: > > tracks > ^ tracks ifNil: [ self tracks: OrderedCollection new ] > > tracks: anObject > tracks := anObject > > Doing something like: > > a := Artist new. > t := Track new. > a tracks add: t > > Gives me the error: > > Artist(Object)>>doesNotUnderstand: #add: > > Once I get past that error, which will evaluate `a tracks`, I can run this. > > I get why it works the second time, but I don't get why it thinks the > instance of Artist is the receiver of add: on the first run. > > Thanks! > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > >

July 25, 2019

Re: [Pharo-users] [OrderedCollection] add a reference or a copy?

by Richard O'Keefe

To a very good approximation, Smalltalk doesn't copy anything unless you ask it to. In this respect it's just like Java, Python, Ruby, ECMAScript, and most OO languages. C++ *does* like to copy things, but it is unusual. On Thu, 25 Jul 2019 at 00:46, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > I think my understanding of OrderedCollections has been incorrect for a > very long time. I have never had a situation where it mattered, but in > modeling a current project, I think I have been approaching it incorrectly. > > Since I have been using Smalltalk, I assumed that a copy of an object is > added to an OrderedCollection. A quick test shows that a reference to that > object is added to the OrderedCollection. > > I just wanted a sanity check on this. Is this true with all collections? > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > >

July 25, 2019