- Pharo-users - lists.pharo.org

Re: [ANN] Pharo bindings for libarchive

by Tim Mackinnon

These are really nice utility things we can leverage (and a great example of the utility of pharo-cig) - thanks for doing this and sharing the work! On Sat, 5 Jul 2025, at 11:18 AM, Esteban Lorenzano via Pharo-users wrote: > Hi, > > As part of my work with pharo-cig <https://github.com/estebanlm/pharo-cig> I am releasing a new pharo library binding. This time for `libarchive`, a multi-format archive and compression library: pharo-archive <https://github.com/estebanlm/pharo-archive>. > > You can read and write any zip file: > > ` > *"list contents of a file"* > | fileRef arc archive paths entryHolder entry | > > arc := *LibArchive* uniqueInstance. > > fileRef := '/path/to/file.zip' asFileReference. > fileRef exists > ifFalse: [ self error: 'File ', fileRef fullName, ' not found.' ]. > > archive := arc read_new. > arc read_support_filter_all: archive. > arc read_support_format_all: archive. > arc > read_open_filenameArg1: archive > _filename: fileRef fullName > _block_size: 10240. > > paths := *OrderedCollection* new. > entryHolder := *ArchiveEntry* newValueHolder. > [ (arc read_next_headerArg1: archive arg2: entryHolder) = 0 ] > whileTrue: [ > entry := entryHolder value. > paths add: (arc entry_pathname: entry). > arc read_data_skip: archive. > ]. > > arc read_free: archive. > > paths inspect ` > Esteban > > 

July 5, 2025

[ANN] Pharo bindings for libarchive

by Esteban Lorenzano

Hi, As part of my work with pharo-cig <https://github.com/estebanlm/pharo-cig> I am releasing a new pharo library binding. This time for |libarchive|, a multi-format archive and compression library: pharo-archive <https://github.com/estebanlm/pharo-archive>. You can read and write any zip file: |"list contents of a file" | fileRef arc archive paths entryHolder entry | arc := LibArchive uniqueInstance. fileRef := '/path/to/file.zip' asFileReference. fileRef exists ifFalse: [ self error: 'File ', fileRef fullName, ' not found.' ]. archive := arc read_new. arc read_support_filter_all: archive. arc read_support_format_all: archive. arc read_open_filenameArg1: archive _filename: fileRef fullName _block_size: 10240. paths := OrderedCollection new. entryHolder := ArchiveEntry newValueHolder. [ (arc read_next_headerArg1: archive arg2: entryHolder) = 0 ] whileTrue: [ entry := entryHolder value. paths add: (arc entry_pathname: entry). arc read_data_skip: archive. ]. arc read_free: archive. paths inspect | Esteban 

July 5, 2025

Pharo News of the Week 27/2025

by Marcus Denker

# Pharo News of the Week 27/2025 - pharo-cig: A tool to import C/C++ libraries into Pharo https://github.com/estebanlm/pharo-cig - pharo-resvg: Pharo bindings for resvg https://github.com/estebanlm/pharo-resvg - ChatPharo: an AI Assistant inside the Pharo environment https://github.com/omarabedelkader/ChatPharo - GeoView: Views to display and interact with geographical objects and cartographic layers https://github.com/ThalesGroup/GeoView - [blog post] Basic Hera Usage as a Video Story https://all-objects-all-the-time.st/#/blog/posts/15 If you want to add your news to this list, use this form: https://tinyurl.com/4c89buy4 # The week on the Pharo Issue Tracker # Fixes - Fix problem with previous completion enh PR - Rescue a lost class. #18360 https://github.com/pharo-project/pharo/pull/18360 - Fix: rename method violators are list and not single instance #18363 https://github.com/pharo-project/pharo/pull/18363 - FilePresenter: Fix cancelling of FilePresenter via UIManager #18314 https://github.com/pharo-project/pharo/pull/18314 # Tools - Fix wrong place for entries #1184 https://github.com/pharo-spec/NewTools/pull/1184 - Fix: window fails to open when message list is nil initially #1193 https://github.com/pharo-spec/NewTools/pull/1193 - Enh/packagescopecompletion #18357 https://github.com/pharo-project/pharo/pull/18357 - Cavrois update profile improvement #1191 https://github.com/pharo-spec/NewTools/pull/1191 # Iceberg - fix: don't throw uncaught exceptions when a validation error occurs #1928 https://github.com/pharo-vcs/iceberg/pull/1928 # Refactoring Engine - Refactor: rename Refactory* classes in Pharo #1192 https://github.com/pharo-spec/NewTools/pull/1192 - Refactor: migrating and cleaning Inline Method refactoring #18359 https://github.com/pharo-project/pharo/pull/18359 - Rename all RBRefactoryChanges into ReChanges #18346 https://github.com/pharo-project/pharo/pull/18346 - Fix a really dumb endless loop in PullUpMethod. #18324 https://github.com/pharo-project/pharo/pull/18324 - Fix Refactoring issue #18212 #18315 https://github.com/pharo-project/pharo/pull/18315 - Add subclass fix #18296 https://github.com/pharo-project/pharo/pull/18296 - Update to class Rename #1189 https://github.com/pharo-spec/NewTools/pull/1189 # Tests - Improve and fix testProperManifestCategorization #18358 https://github.com/pharo-project/pharo/pull/18358 - Adding packages for tests (may be in the future we should truen them â¦ #18361 https://github.com/pharo-project/pharo/pull/18361 - Add comment and executable comments to String>>copyUpToSubstring: #18352 https://github.com/pharo-project/pharo/pull/18352 - Avoid clean blocks for ED tests #18349 https://github.com/pharo-project/pharo/pull/18349 - I added executable comments to withoutSuffix and withoutPrefix in String class #18347 https://github.com/pharo-project/pharo/pull/18347 - Add behaviour preservation tests for Add Method #18321 https://github.com/pharo-project/pharo/pull/18321 # Cleaup - containing is misspelled #718 https://github.com/pharo-project/pharo-launcher/pull/718 - Simplify Stream API #18141 https://github.com/pharo-project/pharo/pull/18141 - Simplify OSEnvironment #18038 https://github.com/pharo-project/pharo/pull/18038 - remove ProfStef and ProfStef-Test from baselines #18310 https://github.com/pharo-project/pharo/pull/18310

July 4, 2025

"Basic Hera Usage as a Video Story " â New blog post on all: objects all: theTime

by Koen De Hondt

Dear Pharo users and developers, In my presentation at ESUG 2025 yesterday, I included some videos about using Hera. If you'd like to watch the videos again, I've written a blog post that includes all the videos, along with the explanation I provided in the presentation. See https://all-objects-all-the-time.st/#/blog/posts/15. Enjoy, Koen

July 2, 2025

ChatPharo - stable version

by Omar Abedelkader

Hey everyone, Iâm happy to share that ChatPharo has now reached its stable release! You can find it here: [ https://github.com/omarabedelkader/ChatPharo | https://github.com/omarabedelkader/ChatPharo ] If you are interested in receiving news about ChatPharo, I have created a broadcast list: chatpharo(a)inria.fr Cheers, Omar -- Omar ABEDELKADER Doctorant, Ãquipe EVREF [ https://www.inria.fr/fr/evref | inria.fr/fr/evref ] [ https://www.cristal.univ-lille.fr/profil/omarabedelkader/ | cristal.univ-lille.fr/omarabedelkader ] / Institut National de Recherche en Sciences et Technologies du NumÃ©rique Parc Scientifique de la Haute Borne Park Plaza - BÃ¢timent A - 40 avenue Halley 59650 Villeneuve d'Ascq - France Si vous lisez ce courriel en dehors de vos heures de travail, merci de ne le traiter quâen cas dâurgence avÃ©rÃ©e. Si ce courriel ne vous est pas destinÃ©, merci de ne pas en prendre connaissance, le dÃ©truire et en informer lâexpÃ©diteur. Merci de nâimprimer ce courriel quâen cas de nÃ©cessitÃ©.

July 2, 2025

Re: New Circular Buffer Implementation for Pharo

by Richard O'Keefe

As promised, here is a further issue from the standard, where I think the standard has a good idea but nobody paid any attention. Smalltalk has a practice of providing conversions between classes when that makes sense. They are named #asResult where Result is the result of the conversion. The "as" prefix is used for no other purpose. In the caseut of things like numbers, we expect that the result will be the closest representable value to the original, and since numbers are theoretically immutable, it doesn't matter whether the receiver or a copy of it is returned when the receiver is already what's wanted. But what about when it *does* matter? What about things like #asArray, #asBag, #asBytearray, #asOrderedCollection, #asSortedCollection, #asSortedCollection:, and #asString? You see, looking at CTFIFOBuffer I noticed the absence of any conversion methods to or from that class, and remember that I didn't have conversion methods to Deque or BoundedDeque either (though those classes inherited a full set of conversion methods *to* them from Collection). So I wondered what guidance the standard provided. Should I just have Collection>>asDeque ^Deque withAll: self or should I override this with Deque>>asDeque ^self On reading the standard closely, I realised two things. First, it took great care to avoid ruling on this. That was a warning sign to me. It indicated a lot of variation between existing Smalltalks of the day with nobody willing to change to a common behaviour. Second, the standard *did* specify an overriding for #asSortedcollection. It says that the result should have the *same* sortBlock as the receiver. SortedCollection>>asSortedCollection ^self copy So I investigated running versions of Smalltalk-80, Squeak, Pharo, GNU Smalltalk, Dolphin [%], VisualWorks, VisualAge, and Smalltalk/X. I found a complete lack of consistency both between Smalltalks and within each Smalltalk (with the single exception of GNU Smalltalk, which always returns a new collection, never the receiver). I also found that nobody had SortedCollection>>asSortedCollection doing the "standard" thing (with the single exception of astc, which does, NOW).. [%] I cannot get Dolphin 8 running on any of my Windows boxes because installing some M$ DLL it depends on doesn't seem to do what it expects. So I had to read the sources. Since I started astc before Pharo existed, I've had a policy of "follow the standard if it's definite and possible, otherwise Squeak". So some of my conversion methods return the receiver when I kind of wish they didn't, but SortedCollection>>asSortedCollection preserves the sortBlock. Now there's a reason for that. In fact there are two. (0) The standard may be intending to allow SortedCollection>>asSortedCollection ^self (1) Preserving the sortBlock means that a *new* SortedCollection can be constructed in linear time without sorting (2) What I call The Principle of Least Crashing: an operation shouldn't fail without good reason. Given a SortedCollection, we have no reason to believe that the default sort block would not crash on its elements. If you supply an explicit sort block, you are taking responsibility for it not crashing. I think it would have been a very good thing had the Smalltalk standard been taken seriously by the people who put it together and by the implementors of the day. We are now in a situation where there is no portable way to open a file, where ScaledDecimal doesn't even *exist* in some Smalltalk systems and is implemented inconsistently in others (and the fact that the ANSI Standard defers definition of ScaledDecimal to the Language Independent Arithmetic standard, which explicitly has nothing to say about the subject, shows me just how seriously the standardisers took their task), oh, I could go on. The ANSI standard left everyone free to do there own user interface, networking, data base, version management, &c &c. But it *does*, with a bit of charitable reading, define a useful base. Trying to implement it has taught me a lot. On Tue, 1 Jul 2025 at 00:23, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I have the final ANSI Smalltalk standard as published. I obviously > cannot give it to you, but I *can* tell you that painfully few of the > obvious errors in the 1.9 draft were corrected. For example, the > DateAndTime class. The basic idea is sound, but we are told that the > range of zone offsets is -12 hours to +12 hours. Well, I live in a > country where the local time is UTC+13 hours for half the year and > part of the country gets up to UTC+13 hours 45 minutes. Then there's > the Line Islands that get up to +14 hours... Worse than that, the > operations on DateAndTime literally *cannot* be implemented as > specified, as they require you to know the leap second rules for > thousands of years in the future. And the standard appears to assume > that all places where the offset from UTC is such and such at one time > has the same offset at all times. It sort of muddles up time zones > with zone OFFSETS and then forgets about zones. The standard also > suffers from being pre-Unicode, so it effectively assumes that random > access by bytes makes sense in external text files. > > There's another problem with the standard, which is that nobody much > seems to have care about it once they'd finished with it. > Case in point: the way to open a file in ANSI Smalltalk is to send a > message to FileStream. Note only did Squeak and Pharo never bother to > implement the standard messages for this purpose, Pharo has even > deleted the class. > > I'll get back to this tomorrow but my battery is about to say bye-bye. > > On Sun, 29 Jun 2025 at 23:29, Alok <zhalok24(a)gmail.com> wrote: > > > > Thnx a lot Richard for such great feedback. We'll definitely update the repo with all the necessary changes. > > > > Thanks Stephane for sharing all the resources. I'll definitely go through ANSI :) > > > > > > On Sun, 29 Jun, 2025, 13:40 Sebastian Jordan, <sebastian.jordan(a)inria.fr> wrote: > >> > >> Hello Richard, > >> > >> Thanks for your feedback. Just for context we are doing this project for the Google Summer of Code. I agree that the buffer should be polymorphic with the OrderedCollection. > >> Yes, we should signal empty collection when accesing an empty buffer (7) > >> > >> We will rok on that and come back to you > >> Sebastian > >> > >> Le 27 juin 2025 Ã 12:23, Richard O'Keefe via Pharo-users <pharo-users(a)lists.pharo.org> a Ã©crit : > >> > >> My own Smalltalk library (and yes, I've tried to put it on github, I > >> don't know what I'm doing wrong) > >> includes Deque and BoundedDeque, both descendants of Collection. > >> Using addLast/removeLast gives you a stack (use #last for peeking) > >> Using addLast/removeFirst gives you a queue. (use #first for peeking) > >> > >> (1) I am puzzled why there are separate FIFO and LIFO classes rather > >> than a single BoundedDeque. > >> -- This has implications for performance. > >> (2) I am puzzled why #withCapacity: is used rather than #new:, > >> familiar from OrderedCollection. > >> -- These two points together make it hard to just swap > >> OrderedCollection and ?IFOBuffer. > >> (3) I am puzzled why #clear is used instead of the familiar #removeAll. > >> -- See note on question 2. > >> (4) I am extremely puzzled why ALL, like ALL, of the internals of the > >> data structure are exposed. > >> Did encapsulation fall out of favour and I didn't get the memo? > >> (5) It looks as though calling #capacity: at the wrong time can > >> destroy the integrity of one of > >> these containers, but there is nothing sayiing "don't do that". > >> (6) I am puzzled that they are not Collections. > >> (7) I am puzzled why trying to access an element in an empty buffer > >> does not signal > >> a CollectionIsEmpty exception > >> -- Is this related to (6)? > >> > >> The structure, with two separate classes and key performance-essential > >> methods being > >> template methods, hurts performance by about a factor of two in my tests. > >> > >> Now Pharo has a design MOOC and if Stephane Ducasse says "this is > >> great", these things > >> that puzzle me must be good design. I would like to improve my > >> skills, so *why* is this good design? > >> (As it happens, I *have* had occasion to 'push' from both ends of a > >> single Deque.) > >> > >> None of this is meant as criticism of the generosity or competence of > >> the authors. It expresses > >> genuine puzzlement. Like when I implemented deques I could not > >> imagine not making them > >> Collections. Principle of Least Surprise and all that. Maybe I > >> should be thinking differently. > >> > >> > >> On Fri, 27 Jun 2025 at 20:10, stephane ducasse via Pharo-users > >> <pharo-users(a)lists.pharo.org> wrote: > >> > >> > >> Thanks this is great! > >> > >> On 18 Jun 2025, at 12:13, Alok via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > >> > >> Hello Everyone, > >> We're excited to share a new addition to the pharo-containers. An efficient Circular Buffer implementation, developed as part of Google Summer of Code 2025 project under the mentorship of Gordana Rakic and Sebastian Jordan MontaÃ±o. > >> > >> This package provides fixed-size buffers supporting both FIFO (queue-style) and LIFO (stack-style) behavior. Itâs designed for use cases such as streaming data, undo/redo functionality, chat or browser history & more. > >> > >> You can find the repo here: Containers-Buffer > >> The README includes usage examples, installation steps etc. > >> > >> Feedback, suggestions, and contributions are very welcome ! > >> ThankYou ! > >> Alok Pathak > >> GSoC'25 Contributor > >> > >> > >> StÃ©phane Ducasse > >> http://stephane.ducasse.free.fr > >> 06 30 93 66 73 > >> > >> "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes > >> > >> > >> > >> > >> > >>

July 1, 2025

Re: New Circular Buffer Implementation for Pharo

by stephane ducasse

ANSI is dead and this is good. Now this is interesting to learn from the analysis and the APIs. > On 30 Jun 2025, at 14:23, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I have the final ANSI Smalltalk standard as published. I obviously > cannot give it to you, but I *can* tell you that painfully few of the > obvious errors in the 1.9 draft were corrected. For example, the > DateAndTime class. The basic idea is sound, but we are told that the > range of zone offsets is -12 hours to +12 hours. Well, I live in a > country where the local time is UTC+13 hours for half the year and > part of the country gets up to UTC+13 hours 45 minutes. Then there's > the Line Islands that get up to +14 hours... Worse than that, the > operations on DateAndTime literally *cannot* be implemented as > specified, as they require you to know the leap second rules for > thousands of years in the future. And the standard appears to assume > that all places where the offset from UTC is such and such at one time > has the same offset at all times. It sort of muddles up time zones > with zone OFFSETS and then forgets about zones. The standard also > suffers from being pre-Unicode, so it effectively assumes that random > access by bytes makes sense in external text files. > > There's another problem with the standard, which is that nobody much > seems to have care about it once they'd finished with it. > Case in point: the way to open a file in ANSI Smalltalk is to send a > message to FileStream. Note only did Squeak and Pharo never bother to > implement the standard messages for this purpose, Pharo has even > deleted the class. > > I'll get back to this tomorrow but my battery is about to say bye-bye. > > On Sun, 29 Jun 2025 at 23:29, Alok <zhalok24(a)gmail.com> wrote: >> >> Thnx a lot Richard for such great feedback. We'll definitely update the repo with all the necessary changes. >> >> Thanks Stephane for sharing all the resources. I'll definitely go through ANSI :) >> >> >> On Sun, 29 Jun, 2025, 13:40 Sebastian Jordan, <sebastian.jordan(a)inria.fr> wrote: >>> >>> Hello Richard, >>> >>> Thanks for your feedback. Just for context we are doing this project for the Google Summer of Code. I agree that the buffer should be polymorphic with the OrderedCollection. >>> Yes, we should signal empty collection when accesing an empty buffer (7) >>> >>> We will rok on that and come back to you >>> Sebastian >>> >>> Le 27 juin 2025 Ã 12:23, Richard O'Keefe via Pharo-users <pharo-users(a)lists.pharo.org> a Ã©crit : >>> >>> My own Smalltalk library (and yes, I've tried to put it on github, I >>> don't know what I'm doing wrong) >>> includes Deque and BoundedDeque, both descendants of Collection. >>> Using addLast/removeLast gives you a stack (use #last for peeking) >>> Using addLast/removeFirst gives you a queue. (use #first for peeking) >>> >>> (1) I am puzzled why there are separate FIFO and LIFO classes rather >>> than a single BoundedDeque. >>> -- This has implications for performance. >>> (2) I am puzzled why #withCapacity: is used rather than #new:, >>> familiar from OrderedCollection. >>> -- These two points together make it hard to just swap >>> OrderedCollection and ?IFOBuffer. >>> (3) I am puzzled why #clear is used instead of the familiar #removeAll. >>> -- See note on question 2. >>> (4) I am extremely puzzled why ALL, like ALL, of the internals of the >>> data structure are exposed. >>> Did encapsulation fall out of favour and I didn't get the memo? >>> (5) It looks as though calling #capacity: at the wrong time can >>> destroy the integrity of one of >>> these containers, but there is nothing sayiing "don't do that". >>> (6) I am puzzled that they are not Collections. >>> (7) I am puzzled why trying to access an element in an empty buffer >>> does not signal >>> a CollectionIsEmpty exception >>> -- Is this related to (6)? >>> >>> The structure, with two separate classes and key performance-essential >>> methods being >>> template methods, hurts performance by about a factor of two in my tests. >>> >>> Now Pharo has a design MOOC and if Stephane Ducasse says "this is >>> great", these things >>> that puzzle me must be good design. I would like to improve my >>> skills, so *why* is this good design? >>> (As it happens, I *have* had occasion to 'push' from both ends of a >>> single Deque.) >>> >>> None of this is meant as criticism of the generosity or competence of >>> the authors. It expresses >>> genuine puzzlement. Like when I implemented deques I could not >>> imagine not making them >>> Collections. Principle of Least Surprise and all that. Maybe I >>> should be thinking differently. >>> >>> >>> On Fri, 27 Jun 2025 at 20:10, stephane ducasse via Pharo-users >>> <pharo-users(a)lists.pharo.org> wrote: >>> >>> >>> Thanks this is great! >>> >>> On 18 Jun 2025, at 12:13, Alok via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>> >>> Hello Everyone, >>> We're excited to share a new addition to the pharo-containers. An efficient Circular Buffer implementation, developed as part of Google Summer of Code 2025 project under the mentorship of Gordana Rakic and Sebastian Jordan MontaÃ±o. >>> >>> This package provides fixed-size buffers supporting both FIFO (queue-style) and LIFO (stack-style) behavior. Itâs designed for use cases such as streaming data, undo/redo functionality, chat or browser history & more. >>> >>> You can find the repo here: Containers-Buffer >>> The README includes usage examples, installation steps etc. >>> >>> Feedback, suggestions, and contributions are very welcome ! >>> ThankYou ! >>> Alok Pathak >>> GSoC'25 Contributor >>> >>> >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr >>> 06 30 93 66 73 >>> >>> "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes >>> >>> >>> >>> >>> >>> StÃ©phane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes

June 30, 2025

Re: New Circular Buffer Implementation for Pharo

by stephane ducasse

Hi richard Thanks for the mail. I would go for the solution 2. 1) Put the test code *inside* the class under test as an extension. Have the test code in the image only when testing. (2) Add the access-to-private-details methods in an extension, included in the image only when testing. (3) What the authors did: reveal all the implementation details to all the world all the time. > On 30 Jun 2025, at 06:22, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Ah, the astc copy you found is years out of date. > And the deque.st you found has had several mistakes fixed since. > > Here's why it mattered to me that these data structures weren't Collections. > > I was writing my own testing and benchmarking code to explore these ones. > They have #isEmpty, so naturally I used both #isEmpty and #notEmpty in my tests. > Not collections, so #notEmpty isn't there. > They have #do:. They don't have #print:, so I threw together some printing code > using the conventional #do:separatedBy:. > Not collections, so #do:separatedBy: isn't there. > Throw in a few non-nil elements, check [b noneSatisfy: [:each | each > isNil]] assert. > Not collections, so #noneSatisfy: isn't there. > Tried to preload a buffer with specified contents using #withAll:. > Not a collection, so #withAll: isn't there. > Tried to compare the result of a series of operations with the expected one. > Not a collection, so #asArray isn't there. > > Now Collection is big. > Collection selectors size ==> 201 > Collection allSelectors size ==> 692 > in Pharo 12. > Collection selectors size ==> 403 > Collection allSelectors size ==> 1091 > in astc with everything included, including compatibility packages, > and a lot of the methods in Collection don't make sense for all descendants. > I've tried very very hard to reduce this in astc, so my Collection > doesn't include #+ . > > Basically, in order to be a "good faith" Collection in astc, you have > to be able to > to #do: multiple times without changing the multiset of items reported and you > have to report #size consistent with this. > > I finally understood why these buffers expose all their implementation details, > and there is arguably an excellent reason for it. There is a question > I would like > advice about, and that's the best way (in Pharo) to accomplish the same purpose > without exposing the implementation. > > Here's the reason. I think of unit tests as testing the externally > visible behaviour > of an object, so that unit tests should only use the public interface > of the objects > they're working with. One reason for this is that I want to be able > to change the > internal details completely without changing the tests. For example, > another way > to implement a deque is using a doubly linked list, and there's no > reason that it > couldn't be bounded, so a *FIFOBuffer might not *have* an elements array or > a readIndex integer, and making such a change leaves the unit tests > still useful. > Well and good: there is *A* category of tests that can and should be restricted > to the public interface. > > But the authors of these buffers went further. They decided to test that the > operations do the right thing the right *way* and created further > tests that check > the internal state of a buffer after an operation. To do this, they > need *access* > to the internal state. > > It seems to me that there are three ways to do this. > (1) Put the test code *inside* the class under test as an extension. > Have the test code in the image only when testing. > (2) Add the access-to-private-details methods in an extension, > included in the image only when testing. > (3) What the authors did: reveal all the implementation details to all the world > all the time. > A fourth theoretical possibility, providing the > access-to-private-details methods > to the test class(es) only, is easy in Eiffel but appears to be > impossible in Smalltalk. > > At this point a confession is appropriate. While testing and benchmarking their > code, I found a discrepancy between their results and mine, and it was MY code > that was broken. (I had tested Deque, but didn't really care about BoundedDeque > very much, so hadn't tested it very thoroughly.) My bug *was* revealed by a > conventional public-interface-only test, but it would have been revealed quicker > by a test-the-implementation test like theirs. So I doff my hat to > the authors for > their thoroughness. > > GIVEN then that testing the implementation as well as the interface is > a good idea, > which of the 3 approaches above is recommended? Is there a still better way? > > > On Sun, 29 Jun 2025 at 16:18, stephane ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Hi richard >> >> BTW guille found your prolog bookon second hand :) >> >> My own Smalltalk library (and yes, I've tried to put it on github, I >> don't know what I'm doing wrong) >> >> >> If you want we can get with it. Just ask and we can do a videos sessions with zoom,m webex, team or whatever software. >> >> includes Deque and BoundedDeque, both descendants of Collection. >> Using addLast/removeLast gives you a stack (use #last for peeking) >> Using addLast/removeFirst gives you a queue. (use #first for peeking) >> >> >> I have found on my disc astc-1711 but I could not find them. >> Can you send us the files? >> >> >> (1) I am puzzled why there are separate FIFO and LIFO classes rather >> than a single BoundedDeque. >> -- This has implications for performance. >> (2) I am puzzled why #withCapacity: is used rather than #new:, >> familiar from OrderedCollection. >> >> >> Good point >> >> -- These two points together make it hard to just swap >> OrderedCollection and ?IFOBuffer. >> >> >> (3) I am puzzled why #clear is used instead of the familiar #removeAll. >> -- See note on question 2. >> >> >> Good point this is nice for API with Collection. >> >> (4) I am extremely puzzled why ALL, like ALL, of the internals of the >> data structure are exposed. >> Did encapsulation fall out of favour and I didn't get the memo? >> (5) It looks as though calling #capacity: at the wrong time can >> destroy the integrity of one of >> these containers, but there is nothing sayiing "don't do that". >> (6) I am puzzled that they are not Collections. >> >> >> What do you mean. >> If this is that they do not inherit from Collection I can understand because the API of collection is large. >> Now Alok it would be good to look at ANSI and see a bit the protocol >> I attach ANSI >> >> (7) I am puzzled why trying to access an element in an empty buffer >> does not signal >> a CollectionIsEmpty exception >> -- Is this related to (6)? >> >> The structure, with two separate classes and key performance-essential >> methods being >> template methods, hurts performance by about a factor of two in my tests. >> >> Now Pharo has a design MOOC and if Stephane Ducasse says "this is >> great", these things >> that puzzle me must be good design. I would like to improve my >> skills, so *why* is this good design? >> (As it happens, I *have* had occasion to 'push' from both ends of a >> single Deque.) >> >> >> I say great because any effort is good, Then we can discuss. >> Iâm currently running a summerschool in parallel to prepare several talks to ESUG and >> finishing the organisation and reviewing other code and more. :) >> >> >> None of this is meant as criticism of the generosity or competence of >> the authors. It expresses >> genuine puzzlement. Like when I implemented deques I could not >> imagine not making them >> Collections. Principle of Least Surprise and all that. Maybe I >> should be thinking differently. >> >> >> On Fri, 27 Jun 2025 at 20:10, stephane ducasse via Pharo-users >> <pharo-users(a)lists.pharo.org> wrote: >> >> >> Thanks this is great! >> >> On 18 Jun 2025, at 12:13, Alok via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> Hello Everyone, >> We're excited to share a new addition to the pharo-containers. An efficient Circular Buffer implementation, developed as part of Google Summer of Code 2025 project under the mentorship of Gordana Rakic and Sebastian Jordan MontaÃ±o. >> >> This package provides fixed-size buffers supporting both FIFO (queue-style) and LIFO (stack-style) behavior. Itâs designed for use cases such as streaming data, undo/redo functionality, chat or browser history & more. >> >> You can find the repo here: Containers-Buffer >> The README includes usage examples, installation steps etc. >> >> Feedback, suggestions, and contributions are very welcome ! >> ThankYou ! >> Alok Pathak >> GSoC'25 Contributor >> >> >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> 06 30 93 66 73 >> >> "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes >> >> >> >> >> >> >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> 06 30 93 66 73 >> >> "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes >> >> >> >> >> StÃ©phane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes

June 30, 2025

Re: New Circular Buffer Implementation for Pharo

by Richard O'Keefe

I have the final ANSI Smalltalk standard as published. I obviously cannot give it to you, but I *can* tell you that painfully few of the obvious errors in the 1.9 draft were corrected. For example, the DateAndTime class. The basic idea is sound, but we are told that the range of zone offsets is -12 hours to +12 hours. Well, I live in a country where the local time is UTC+13 hours for half the year and part of the country gets up to UTC+13 hours 45 minutes. Then there's the Line Islands that get up to +14 hours... Worse than that, the operations on DateAndTime literally *cannot* be implemented as specified, as they require you to know the leap second rules for thousands of years in the future. And the standard appears to assume that all places where the offset from UTC is such and such at one time has the same offset at all times. It sort of muddles up time zones with zone OFFSETS and then forgets about zones. The standard also suffers from being pre-Unicode, so it effectively assumes that random access by bytes makes sense in external text files. There's another problem with the standard, which is that nobody much seems to have care about it once they'd finished with it. Case in point: the way to open a file in ANSI Smalltalk is to send a message to FileStream. Note only did Squeak and Pharo never bother to implement the standard messages for this purpose, Pharo has even deleted the class. I'll get back to this tomorrow but my battery is about to say bye-bye. On Sun, 29 Jun 2025 at 23:29, Alok <zhalok24(a)gmail.com> wrote: > > Thnx a lot Richard for such great feedback. We'll definitely update the repo with all the necessary changes. > > Thanks Stephane for sharing all the resources. I'll definitely go through ANSI :) > > > On Sun, 29 Jun, 2025, 13:40 Sebastian Jordan, <sebastian.jordan(a)inria.fr> wrote: >> >> Hello Richard, >> >> Thanks for your feedback. Just for context we are doing this project for the Google Summer of Code. I agree that the buffer should be polymorphic with the OrderedCollection. >> Yes, we should signal empty collection when accesing an empty buffer (7) >> >> We will rok on that and come back to you >> Sebastian >> >> Le 27 juin 2025 Ã 12:23, Richard O'Keefe via Pharo-users <pharo-users(a)lists.pharo.org> a Ã©crit : >> >> My own Smalltalk library (and yes, I've tried to put it on github, I >> don't know what I'm doing wrong) >> includes Deque and BoundedDeque, both descendants of Collection. >> Using addLast/removeLast gives you a stack (use #last for peeking) >> Using addLast/removeFirst gives you a queue. (use #first for peeking) >> >> (1) I am puzzled why there are separate FIFO and LIFO classes rather >> than a single BoundedDeque. >> -- This has implications for performance. >> (2) I am puzzled why #withCapacity: is used rather than #new:, >> familiar from OrderedCollection. >> -- These two points together make it hard to just swap >> OrderedCollection and ?IFOBuffer. >> (3) I am puzzled why #clear is used instead of the familiar #removeAll. >> -- See note on question 2. >> (4) I am extremely puzzled why ALL, like ALL, of the internals of the >> data structure are exposed. >> Did encapsulation fall out of favour and I didn't get the memo? >> (5) It looks as though calling #capacity: at the wrong time can >> destroy the integrity of one of >> these containers, but there is nothing sayiing "don't do that". >> (6) I am puzzled that they are not Collections. >> (7) I am puzzled why trying to access an element in an empty buffer >> does not signal >> a CollectionIsEmpty exception >> -- Is this related to (6)? >> >> The structure, with two separate classes and key performance-essential >> methods being >> template methods, hurts performance by about a factor of two in my tests. >> >> Now Pharo has a design MOOC and if Stephane Ducasse says "this is >> great", these things >> that puzzle me must be good design. I would like to improve my >> skills, so *why* is this good design? >> (As it happens, I *have* had occasion to 'push' from both ends of a >> single Deque.) >> >> None of this is meant as criticism of the generosity or competence of >> the authors. It expresses >> genuine puzzlement. Like when I implemented deques I could not >> imagine not making them >> Collections. Principle of Least Surprise and all that. Maybe I >> should be thinking differently. >> >> >> On Fri, 27 Jun 2025 at 20:10, stephane ducasse via Pharo-users >> <pharo-users(a)lists.pharo.org> wrote: >> >> >> Thanks this is great! >> >> On 18 Jun 2025, at 12:13, Alok via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> Hello Everyone, >> We're excited to share a new addition to the pharo-containers. An efficient Circular Buffer implementation, developed as part of Google Summer of Code 2025 project under the mentorship of Gordana Rakic and Sebastian Jordan MontaÃ±o. >> >> This package provides fixed-size buffers supporting both FIFO (queue-style) and LIFO (stack-style) behavior. Itâs designed for use cases such as streaming data, undo/redo functionality, chat or browser history & more. >> >> You can find the repo here: Containers-Buffer >> The README includes usage examples, installation steps etc. >> >> Feedback, suggestions, and contributions are very welcome ! >> ThankYou ! >> Alok Pathak >> GSoC'25 Contributor >> >> >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> 06 30 93 66 73 >> >> "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes >> >> >> >> >> >>

June 30, 2025

[ANN] pharo bindings for resvg library

by Esteban Lorenzano

Hi, As part of my work with pharo-cig <https://github.com/estebanlm/pharo-cig> I am releasing a new pharo library binding. This time for ReSVG, a parser and render library for SVG images: pharo-resvg <https://github.com/estebanlm/pharo-resvg>. You can parse any file and get a Form without effort : Esteban 

June 30, 2025