- Pharo-dev - lists.pharo.org

[ANN] UTF8String

by Sven Van Caekenberghe

Hi, I recently revised some code that I wrote in 2019 and prepared it for publication. UTF8String is a proof of concept / prototype alternative String implementation for Pharo using a variable length UTF8 encoded internal representation. There is a writeup with more details in the README on GitHub: https://github.com/svenvc/UTF8String The public methods are commented and there are some basic unit tests. Just like the experiment of a SubString class that is just a [from,to] pair on an existing (readonly) String (which I believe someone once did, but I can't remember the details), this is another idea that might maybe one day be useful. Sven

March 9, 2022

This week (09/2022) on the Pharo Issue Tracker

by Marcus Denker

Not much this week due to PharoDaysâ¦ but we fixed 5 issues: - Macro expand expects a string and not a smallInteger (fixes #10859: Removing a game controler opens a debugger in Pharo) #10968 https://github.com/pharo-project/pharo/pull/10968 - 10960-ReClassSideResetMethodProtocolRule-is-not-checking-for-class-side #10961 https://github.com/pharo-project/pharo/pull/10961 - AllProtocol should not initialize unused ivar #10964 https://github.com/pharo-project/pharo/pull/10964 - 10939 calypso contextual menus display debugging and breakpoint commands in different ways #10944 https://github.com/pharo-project/pharo/pull/10944 - Fix Calypso toolbar layout to prevent buttons in browser from hiding #10938 https://github.com/pharo-project/pharo/pull/10938

March 5, 2022

This week (08/2022) on the Pharo Issue Tracker

by Marcus Denker

This week (08/2022) on the Pharo Issue Tracker More cleanups and fixes to prepare the release of Pharo10 Fixes ===== - Make the patcher more robust #10950 https://github.com/pharo-project/pharo/pull/10950 - Fix issue 10949 by checking correctly windows platform #10953 https://github.com/pharo-project/pharo/pull/10953 - Update zinc to the latest version #10901 https://github.com/pharo-project/pharo/pull/10901 - 10860-Debugger-hightlights-the-wrong-line-in-test-for-asserts-inside-two-identical-blocks #10893 https://github.com/pharo-project/pharo/pull/10893 - New try at removing Pharo 9 metacello attributes #10819 https://github.com/pharo-project/pharo/pull/10819 - Full block cleanup: #sourceNodeForPC: RBBlockNode #10888 https://github.com/pharo-project/pharo/pull/10888 Cleanup ======= - Simplify-allUnimplementedCalls #10932 https://github.com/pharo-project/pharo/pull/10932 - CompiledCode-hasTemporaries #10936 https://github.com/pharo-project/pharo/pull/10936 - More Cleanup newlines and blanks in packages e.g https://github.com/pharo-project/pharo/pull/10941 - Wrong example in Dictionary>>#associationsDo: comment #10927 #10931 https://github.com/pharo-project/pharo/pull/10931

March 1, 2022

Re: Migration of ReferenceFinder

by pmissech

Oh, I was not aware. I have been loading it every time I've needed it from the smalltalkhub directory ! I guess i'll remove the repository then, issues for it should probably be on the Pharo repository ! Pierre On 01/03/2022 13:30, John Brant wrote: > The ReferenceFinder class is the one I wrote for the Refactoring Browser and then converted to Pharo. It is under the MIT license. It is already part of the Pharo image (https://github.com/pharo-project/pharo/tree/Pharo10/src/ReferenceFinder-Core) > > > John Brant > >> On Feb 27, 2022, at 10:03 PM, Pierre Misse Chanabier <pierre.misse-chanabier(a)inria.fr> wrote: >> >> I'm assuming you're talking about https://github.com/pavel-krivanek/RefsHunter ? >> (That's the only one I saw on Pavel's account) >> >> From a quick look, it seems like a different implementation which rely on a snapshot of the memory. >> But I haven't looked very deep at all. >> >> Pierre >> >> On 2/27/2022 9:23 PM, stephane ducasse wrote: >>> Thanks Pierre >>> Do you know how it compares with the port of Pavel Krivanek? >>> >>> S >>> >>>> On 25 Feb 2022, at 15:20, pmissech <pierre.misse-chanabier(a)inria.fr> wrote: >>>> >>>> Hello, >>>> >>>> I've migrated the small repository of Reference Finder to github: https://github.com/hogoww/ReferenceFinder/ from Smalltalk-hub. >>>> If someone is aware of another migration of the repository, licensing or others, please let me know. >>>> >>>> Pierre

March 1, 2022

Re: Migration of ReferenceFinder

by John Brant

The ReferenceFinder class is the one I wrote for the Refactoring Browser and then converted to Pharo. It is under the MIT license. It is already part of the Pharo image (https://github.com/pharo-project/pharo/tree/Pharo10/src/ReferenceFinder-Core) John Brant > On Feb 27, 2022, at 10:03 PM, Pierre Misse Chanabier <pierre.misse-chanabier(a)inria.fr> wrote: > > I'm assuming you're talking about https://github.com/pavel-krivanek/RefsHunter ? > (That's the only one I saw on Pavel's account) > > From a quick look, it seems like a different implementation which rely on a snapshot of the memory. > But I haven't looked very deep at all. > > Pierre > > On 2/27/2022 9:23 PM, stephane ducasse wrote: >> Thanks Pierre >> Do you know how it compares with the port of Pavel Krivanek? >> >> S >> >>> On 25 Feb 2022, at 15:20, pmissech <pierre.misse-chanabier(a)inria.fr> wrote: >>> >>> Hello, >>> >>> I've migrated the small repository of Reference Finder to github: https://github.com/hogoww/ReferenceFinder/ from Smalltalk-hub. >>> If someone is aware of another migration of the repository, licensing or others, please let me know. >>> >>> Pierre

March 1, 2022

Re: [ANN] Fuel 5.0.0

by Martin Dias

On Sun, Feb 27, 2022 at 4:42 PM stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > Great news! > +1 thanks Max! MartÃn > On 27 Feb 2022, at 19:34, Max Leske <maxleske(a)gmail.com> wrote: > > Hi everyone, > > I'm happy to announce Fuel version 5.0.0 today. > > The changes to 4.0.0 aren't huge but I've had to adjust the format once more. > > 5.0.0 comes with full support for stateful traits, i.e. traits with instance variables. You can find the release notes here: https://theseion.github.io/Fuel/releases/5.0.0/. > > > Cheers, > Max (on behalf of the Fuel team) > >

March 1, 2022

Re: [ANN] Fuel 5.0.0

by Chris Muller

> > You will never be able to invent the future if you do not want to have a > future. > The future cannot be had, only the present.

March 1, 2022

Re: [ANN] Fuel 5.0.0

by Marcus Denker

> On 28 Feb 2022, at 22:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 28 Feb 2022, at 21:43, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 28 Feb 2022, at 20:55, Marcus Denker wrote: >> >>>>> >>>>> Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance >>>>> variablesâ¦ (which is the right thing to do now), but that would not work here anymore. >>>> >>>> Good to know. I'll have to think about how this plays together with the "classic" architecture. >>>> >>> >>> >>> This is why I am in general not a fan of this idea of code trying to be compatible on that levelâ¦ >>> >>> To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do >>> and do *more*. To take the philosophy and push it furtherâ¦ but that can *not* be done if one >>> want to 100% backward compatible on an implementation level forever... >>> >>> I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-) >> >> lol :D >> >> I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll reach a point where it becomes easier to maintain >> two separate versions. As long as there are users in Squeak I want to support them (maybe I'll do a survey >> in the Squeak community at that point, it could also be an option to drop support for Squeak if they don't >> use Fuel). >> > > It was explained to me, when I said âWe did Pharo to have a futureâ, that *nobody* in the Squeak community wants or ever wanted > to have a future. and that this is good for eToys.. I still do not understand that. It just made no sense.But then, in retrospect, not much made sense with Squeak. You will never be able to invent the future if you do not want to have a future. Marcus

Feb. 28, 2022

Re: [ANN] Fuel 5.0.0

by Marcus Denker

> On 28 Feb 2022, at 21:43, Max Leske <maxleske(a)gmail.com> wrote: > > On 28 Feb 2022, at 20:55, Marcus Denker wrote: > >>>> >>>> Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance >>>> variablesâ¦ (which is the right thing to do now), but that would not work here anymore. >>> >>> Good to know. I'll have to think about how this plays together with the "classic" architecture. >>> >> >> >> This is why I am in general not a fan of this idea of code trying to be compatible on that levelâ¦ >> >> To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do >> and do *more*. To take the philosophy and push it furtherâ¦ but that can *not* be done if one >> want to 100% backward compatible on an implementation level forever... >> >> I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-) > > lol :D > > I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll reach a point where it becomes easier to maintain > two separate versions. As long as there are users in Squeak I want to support them (maybe I'll do a survey > in the Squeak community at that point, it could also be an option to drop support for Squeak if they don't > use Fuel). > It was explained to me, when I said âWe did Pharo to have a futureâ, that *nobody* in the Squeak community wants or ever wanted to have a future. So why waste even 5 minutes on that? Marcus

Feb. 28, 2022

Re: [ANN] Fuel 5.0.0

by Max Leske

On 28 Feb 2022, at 20:55, Marcus Denker wrote: >>> >>> Fuel for now just ignores the whole âFirst class Variableâ concept and serialises the ârawâ view of indexed instance >>> variablesâ¦ (which is the right thing to do now), but that would not work here anymore. >> >> Good to know. I'll have to think about how this plays together with the "classic" architecture. >> > > > This is why I am in general not a fan of this idea of code trying to be compatible on that levelâ¦ > > To me what fascinated me about Squeak was not to be slavishly compatible to ST80, but to do > and do *more*. To take the philosophy and push it furtherâ¦ but that can *not* be done if one > want to 100% backward compatible on an implementation level forever... > > I think my next talk at ESUG will be âWhy I am not a Smalltalkerâ. :-) lol :D I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll reach a point where it becomes easier to maintain two separate versions. As long as there are users in Squeak I want to support them (maybe I'll do a survey in the Squeak community at that point, it could also be an option to drop support for Squeak if they don't use Fuel). > > Marcus

Feb. 28, 2022