April 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Handling of deprecation packages

by ducasse

> Hi Stef, > > It's not a big problem. I primary wanted to ask what is the status and overall plan. > > The problem with the new vs. old streams seems to be that migration is unfinished even for the base image. If you find some let us know. The objective is to be able to remove the old stream packages and I thought that we were there. > Development already switched quickly to newer construction sites instead of finishing these old ones. Not really, we are mainly making sure that - Schmidt is able to work on their migration (it means be able to use Spec2) - Improving Windows support as well as speed problems as for Lifeware. > That does not mean that I do not appreciate the new journeys Pharo 8 will bring - but it still gives this > bad feeling of important transitions are incomplete and should have been addressed first. We do not share this completely but I understand your point. Now given the state of the old streams I think that guille did a ***massive*** amount of work. > That's why also "Deprecated70" could not easily get removed. And there is no guide in how to migrate to the new stream. Did you check the comments of Stream? > At least I do not know of something that could quickly explain on how to convert. The problem is that with the old stream you could change in the middle from binary to text and vice versa in an insane way. > If we integrate a "Deprecated80" (which I think we should do to continue deprecating stuff like required > for issue #3186) it could easily lead to confusion when we have two deprecated packages. Sure go ahead and propose a new package. > For "Deprecated70" and "Deprecated80" it might be clear from the name but as for P7 there were also > deprecations for other packages like "Ring-Deprecated*" it might not be clear over time when and how > they were deprecated. Yes we should really remove Ring and for this one this is unfinished. > The previous scheme we used to directly remove old deprecations when a new Pharo release iteration started > was at least more clear and I think it helped people to better sort out what and when to stop using stuff. Did you try to remove the old streams and got problems? Because this is something that we should try. S. Iâm away from computers and digging a pond in my garden. Will back to Pharo next week. > > Bye > T. > > >> Gesendet: Donnerstag, 18. April 2019 um 08:26 Uhr >> Von: "ducasse" <stepharo(a)netcourrier.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] Handling of deprecation packages >> >> Hi torsten >> >> I do not remember if I migrated deprecated70 to the migrator package. >> I should check but if someone else wants to have a look even better. >> Then my thought was that the streams are important and making the live of people easier to migrate >> important too especially since we cannot fully automate Stream deprecation. >> >> Now I would like to understand why this is so a problem for you? >> >> Stef >> >>> On 17 Apr 2019, at 23:15, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Hi, >>> >>> in the past after each release iteration one of the first things applied to a new development image >>> - was to remove the "DeprecatedXX" package of the previous version XX >>> - and add a new "DeprecatedYY" package for the new pharo version YY >>> >>> This allowed then to mark classes that should get obsolete for version YY and put them into "DeprecatedYY" >>> >>> But in current Pharo 8 dev image we still have the "Deprecated70" package inside and a new "Deprecated80" >>> is not yet opened. >>> >>> I know there >>> - were some discussion about having a "migrator" tool first to help in the transition to the new release >>> (but I guess this "migrator" could be written using P7 image, no?) >>> >>> - we can also not just delete "Deprecated70" as StandardFileStream, MultiByteFileStream and others are >>> still useds in the code without giving a proper >>> >>> So I wonder what is the status and on plan this in P8 >>> >>> Thx >>> T. >>> >> >> >> >> >

April 18, 2019

Re: [Pharo-dev] Roassal Animations

by ducasse

Yes norbert this is the idea and this is why I created u(Micro)UML Check on github this is super naive but I should add support for position and we will be able to script Iâm brainstorming with the âsyntaxâ MUMLTest >> setUp [ lab := UMLClass <~ 'Lab' instVar: 'topic'. student := UMLClass <~ 'Student' instVar: 'ID'. ] UMLAssociation <~ âenrolment' one: student toMany: lab. > On 18 Apr 2019, at 07:42, Norbert Hartl <norbert(a)hartl.name> wrote: > > Great! Will this be part of the minimal roassal? That could improve documentation quite a bit. > > Norbert > > Am 18.04.2019 um 01:05 schrieb Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > >> Hi! >> >> Just as a follow up, we have a UML diagram builder for Roassal3. >> >> You can load Roassal3 using: >> Metacello new >> baseline: 'Roassal3'; >> repository: 'github://ObjectProfile/Roassal3/src <github://ObjectProfile/Roassal3/src>'; >> load. >> >> As indicated on https://github.com/ObjectProfile/Roassal3 <https://github.com/ObjectProfile/Roassal3> >> >> An UML class diagram can be open using: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> | builder pharoClassesToBeVisualized | >> >> "Zooming and position of the view can be controled using the keys: >> I O Space >> Arrows >> " >> >> pharoClassesToBeVisualized := >> TSAbstractLine >> withAllSubclasses. >> >> builder := >> RSUMLClassBuilder >> new. >> builder classes: pharoClassesToBeVisualized. >> >> builder classDescriptor >> methods: [ :cls | | methods | >> methods := cls methods sorted: [ :a :b | >> a selector < b selector ] ]. >> >> builder build. >> builder view when: >> TSExtentChangedEvent >> do: [ builder view zoomToFit ]. >> builder open >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> We now do have a support for UML class diagrams and we can easily add new features, if wanted. >> >> >> >> Cheers, >> Alexandre & Milton >> >> >>> On Mar 27, 2019, at 3:37 PM, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >>> >>> >>> >>>> On 27 Mar 2019, at 18:27, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>>> >>>> >>>> From: Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> >>>> Subject: Re: [Pharo-dev] Roassal Animations >>>> Date: 27 March 2019 at 18:27:28 CET >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >>>> >>>> >>>> Thanks to all of you for your nice words. >>>> These posts are a teaser of what is coming. Code of each animation is part of Roassal3. Note that we have made no official announcement, simply because Roassal3 is still well behind Roassal2 in terms of offered features. Actually, you cannot do much with Roassal3, beside having cool visualization. >>>> >>>> We will tell you more soon, once we have a UML renderer and code dependency visualizer :-) >>>> >>>> We are currently working on a nice distribution that can be shipped within Pharo 8. >>> >>> :) >>> >>> >>

April 18, 2019

Re: [Pharo-dev] Roassal Animations

by ducasse

This is cool. With my package uUML we can represent the documentation and I was planning to add coordinates. The idea is that the uUML object should contain the exact positions like that we can always build the same. stef > On 18 Apr 2019, at 01:05, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > Just as a follow up, we have a UML diagram builder for Roassal3. > > You can load Roassal3 using: > Metacello new > baseline: 'Roassal3'; > repository: 'github://ObjectProfile/Roassal3/src <github://ObjectProfile/Roassal3/src>'; > load. > > As indicated on https://github.com/ObjectProfile/Roassal3 <https://github.com/ObjectProfile/Roassal3> > > An UML class diagram can be open using: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | builder pharoClassesToBeVisualized | > > "Zooming and position of the view can be controled using the keys: > I O Space > Arrows > " > > pharoClassesToBeVisualized := > TSAbstractLine > withAllSubclasses. > > builder := > RSUMLClassBuilder > new. > builder classes: pharoClassesToBeVisualized. > > builder classDescriptor > methods: [ :cls | | methods | > methods := cls methods sorted: [ :a :b | > a selector < b selector ] ]. > > builder build. > builder view when: > TSExtentChangedEvent > do: [ builder view zoomToFit ]. > builder open > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > We now do have a support for UML class diagrams and we can easily add new features, if wanted. > > <scriptOfTheDay.png> > > Cheers, > Alexandre & Milton > > >> On Mar 27, 2019, at 3:37 PM, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >> >> >> >>> On 27 Mar 2019, at 18:27, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>> >>> >>> From: Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> >>> Subject: Re: [Pharo-dev] Roassal Animations >>> Date: 27 March 2019 at 18:27:28 CET >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >>> >>> >>> Thanks to all of you for your nice words. >>> These posts are a teaser of what is coming. Code of each animation is part of Roassal3. Note that we have made no official announcement, simply because Roassal3 is still well behind Roassal2 in terms of offered features. Actually, you cannot do much with Roassal3, beside having cool visualization. >>> >>> We will tell you more soon, once we have a UML renderer and code dependency visualizer :-) >>> >>> We are currently working on a nice distribution that can be shipped within Pharo 8. >> >> :) >> >> >

April 18, 2019

Re: [Pharo-dev] Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"

by Serge Stinckwich

Any news on this ? This is only a 32 bits VM problem ? Why when I install Pillar on MacOS, the 32bits VM is used and not 64bits VM ? On Fri, May 11, 2018 at 11:37 AM <serge.stinckwich(a)gmail.com> wrote: > Yes this is just a little bit annoying when you use Pillar because you > have a lot of noise ;-) > > EnvoyÃ© de mon iPhone > > > Le 11 mai 2018 Ã 17:17, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit > : > > > > This is a problem since more than one year. > > Apple changed something on their apis and nobody knows how to fix it. > > > > but it is just a warning and you can work normally anyway :) > > > > cheers, > > Esteban > > > >> On 11 May 2018, at 00:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Yeah, I saw that for a while too, but my 64bit P7 VMs from the last > couple of days don't do this anymore. > >> I don't know why. > >> > >>> On 10 May 2018, at 23:53, Tim Mackinnon <tim(a)testit.works> wrote: > >>> > >>> I noticed that recent Pharo 6.1 zero conf downloads show lots of these > errors when you run the image in the terminal. Previous versions didnât do > this - is this something to do with the latest vm upgrade? > >>> > >>> ./pharo-ui PagerDuty.image > >>> > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: > Error: unsupported compressor 8 > >>> > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: > Error: Unknown compression scheme encountered for file > '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' > >>> > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: > Error: unsupported compressor 8 > >>> > /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: > Error: Unknown compression scheme encountered for file > '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' > >>> > >>> > >>> Tim > >> > >> > > > > > -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

April 18, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0.3

by Tim Mackinnon

> On 17 Apr 2019, at 23:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Somebody should just decide that new version needs to be to back ported. Who is the somebody that would decide? If we have to live with Pharo 7.x for the next year (possibly a bit less) - some of the UI fixes would be much appreciated, particularly if its easy to do. Perhaps if we do a 7.0.4 we might do that? Tim p.s. 7.0.3 definitely doesnât fix the font glitch (sadly), and Guilleâs fix cause my image to deadlock for 3-5 minutes when I see it (which might actually be helpful - is it could conform a specific type of problem)

April 18, 2019

Re: [Pharo-dev] [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Norbert Hartl

Great! Can you explain what is there, what somebody can load and what to expect. And even more important: what not to expect? I donât get any of the essential details from this mail. Norbert > Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: > > We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! > > Why we want a Spec 2.0 with different backends? > > There are reasons that converged to decide us to make it: > > First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). > Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: > Because there is still an important place for desktop applications market and most medium-size to big business still require them. > Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). > > For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. > > Why Gtk3? > > There are some other important players in the "native widgets scene", so why we choose Gtk3? > > Again, several reasons were taken into account: > > Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. > It is very mature and popular. > It is made in plain C. > > Next step: tool migration > > The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: > > Old GT tools will be replaced by new Spec tools (while preserving its power). > Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). > Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. > > And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) > > > A small screenshot of the new Inspector (WIP): > > <Screenshot 2019-04-18 at 12.07.16.png> > > Esteban

April 18, 2019

Re: [Pharo-dev] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Esteban Lorenzano

Ah yesâ¦ and same in morphic (but this is kind of boring ;): > On 18 Apr 2019, at 12:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: > > We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! > > Why we want a Spec 2.0 with different backends? > > There are reasons that converged to decide us to make it: > > First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). > Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: > Because there is still an important place for desktop applications market and most medium-size to big business still require them. > Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). > > For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. > > Why Gtk3? > > There are some other important players in the "native widgets scene", so why we choose Gtk3? > > Again, several reasons were taken into account: > > Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. > It is very mature and popular. > It is made in plain C. > > Next step: tool migration > > The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: > > Old GT tools will be replaced by new Spec tools (while preserving its power). > Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). > Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. > > And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) > > > A small screenshot of the new Inspector (WIP): > > <Screenshot 2019-04-18 at 12.07.16.png> > > Esteban

April 18, 2019

[ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Esteban Lorenzano

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings! Why we want a Spec 2.0 with different backends? There are reasons that converged to decide us to make it: First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic). Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the "next big thing" (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: Because there is still an important place for desktop applications market and most medium-size to big business still require them. Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it). For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless: Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come. Why Gtk3? There are some other important players in the "native widgets scene", so why we choose Gtk3? Again, several reasons were taken into account: Gtk3 is cross platform. Yes, technically is just "native" in linux, but it works on Windows and macOS too. It is very mature and popular. It is made in plain C. Next step: tool migration The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: Old GT tools will be replaced by new Spec tools (while preserving its power). Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings. And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately :) A small screenshot of the new Inspector (WIP): Esteban

April 18, 2019

[ANN] Next Pharo Sprint: April 26

by Marcus Denker

We will organize a Pharo sprint / Moose dojo April 26, starting at 10:00am. (Local Time Paris). Goals of this sprint: - Pharo 8: Fix issues from tracker https://github.com/pharo-project/pharo/issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come

April 18, 2019

[Pharo 8.0] Build #230: 3199 Cleanup testAsBit methods

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #230 was: SUCCESS. The Pull Request #3200 was integrated: "3199 Cleanup testAsBit methods" Pull request url: https://github.com/pharo-project/pharo/pull/3200 Issue Url: https://github.com/pharo-project/pharo/issues/3199 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 18, 2019

[Pharo 8.0] Build #229: Fixing the broken test

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #229 was: FAILURE. The Pull Request #3195 was integrated: "Fixing the broken test" Pull request url: https://github.com/pharo-project/pharo/pull/3195 Issue Url: https://github.com/pharo-project/pharo/issues/fixing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 18, 2019

Re: [Pharo-dev] Handling of deprecation packages

by Torsten Bergmann

Hi Stef, It's not a big problem. I primary wanted to ask what is the status and overall plan. The problem with the new vs. old streams seems to be that migration is unfinished even for the base image. Development already switched quickly to newer construction sites instead of finishing these old ones. That does not mean that I do not appreciate the new journeys Pharo 8 will bring - but it still gives this bad feeling of important transitions are incomplete and should have been addressed first. That's why also "Deprecated70" could not easily get removed. And there is no guide in how to migrate to the new stream. At least I do not know of something that could quickly explain on how to convert. If we integrate a "Deprecated80" (which I think we should do to continue deprecating stuff like required for issue #3186) it could easily lead to confusion when we have two deprecated packages. For "Deprecated70" and "Deprecated80" it might be clear from the name but as for P7 there were also deprecations for other packages like "Ring-Deprecated*" it might not be clear over time when and how they were deprecated. The previous scheme we used to directly remove old deprecations when a new Pharo release iteration started was at least more clear and I think it helped people to better sort out what and when to stop using stuff. Bye T. > Gesendet: Donnerstag, 18. April 2019 um 08:26 Uhr > Von: "ducasse" <stepharo(a)netcourrier.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Handling of deprecation packages > > Hi torsten > > I do not remember if I migrated deprecated70 to the migrator package. > I should check but if someone else wants to have a look even better. > Then my thought was that the streams are important and making the live of people easier to migrate > important too especially since we cannot fully automate Stream deprecation. > > Now I would like to understand why this is so a problem for you? > > Stef > > > On 17 Apr 2019, at 23:15, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > in the past after each release iteration one of the first things applied to a new development image > > - was to remove the "DeprecatedXX" package of the previous version XX > > - and add a new "DeprecatedYY" package for the new pharo version YY > > > > This allowed then to mark classes that should get obsolete for version YY and put them into "DeprecatedYY" > > > > But in current Pharo 8 dev image we still have the "Deprecated70" package inside and a new "Deprecated80" > > is not yet opened. > > > > I know there > > - were some discussion about having a "migrator" tool first to help in the transition to the new release > > (but I guess this "migrator" could be written using P7 image, no?) > > > > - we can also not just delete "Deprecated70" as StandardFileStream, MultiByteFileStream and others are > > still useds in the code without giving a proper > > > > So I wonder what is the status and on plan this in P8 > > > > Thx > > T. > > > > > >

April 18, 2019

Re: [Pharo-dev] Handling of deprecation packages

by ducasse

Hi torsten I do not remember if I migrated deprecated70 to the migrator package. I should check but if someone else wants to have a look even better. Then my thought was that the streams are important and making the live of people easier to migrate important too especially since we cannot fully automate Stream deprecation. Now I would like to understand why this is so a problem for you? Stef > On 17 Apr 2019, at 23:15, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > in the past after each release iteration one of the first things applied to a new development image > - was to remove the "DeprecatedXX" package of the previous version XX > - and add a new "DeprecatedYY" package for the new pharo version YY > > This allowed then to mark classes that should get obsolete for version YY and put them into "DeprecatedYY" > > But in current Pharo 8 dev image we still have the "Deprecated70" package inside and a new "Deprecated80" > is not yet opened. > > I know there > - were some discussion about having a "migrator" tool first to help in the transition to the new release > (but I guess this "migrator" could be written using P7 image, no?) > > - we can also not just delete "Deprecated70" as StandardFileStream, MultiByteFileStream and others are > still useds in the code without giving a proper > > So I wonder what is the status and on plan this in P8 > > Thx > T. >

April 18, 2019

Re: [Pharo-dev] Roassal Animations

by Norbert Hartl

Great! Will this be part of the minimal roassal? That could improve documentation quite a bit. Norbert > Am 18.04.2019 um 01:05 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > Just as a follow up, we have a UML diagram builder for Roassal3. > > You can load Roassal3 using: > Metacello new > baseline: 'Roassal3'; > repository: 'github://ObjectProfile/Roassal3/src'; > load. > > As indicated on https://github.com/ObjectProfile/Roassal3 > > An UML class diagram can be open using: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | builder pharoClassesToBeVisualized | > > "Zooming and position of the view can be controled using the keys: > I O Space > Arrows > " > > pharoClassesToBeVisualized := > TSAbstractLine > withAllSubclasses. > > builder := > RSUMLClassBuilder > new. > builder classes: pharoClassesToBeVisualized. > > builder classDescriptor > methods: [ :cls | | methods | > methods := cls methods sorted: [ :a :b | > a selector < b selector ] ]. > > builder build. > builder view when: > TSExtentChangedEvent > do: [ builder view zoomToFit ]. > builder open > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > We now do have a support for UML class diagrams and we can easily add new features, if wanted. > > > > Cheers, > Alexandre & Milton > > >> On Mar 27, 2019, at 3:37 PM, ducasse <stepharo(a)netcourrier.com> wrote: >> >> >> >>> On 27 Mar 2019, at 18:27, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> >>> From: Alexandre Bergel <alexandre.bergel(a)me.com> >>> Subject: Re: [Pharo-dev] Roassal Animations >>> Date: 27 March 2019 at 18:27:28 CET >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> >>> >>> Thanks to all of you for your nice words. >>> These posts are a teaser of what is coming. Code of each animation is part of Roassal3. Note that we have made no official announcement, simply because Roassal3 is still well behind Roassal2 in terms of offered features. Actually, you cannot do much with Roassal3, beside having cool visualization. >>> >>> We will tell you more soon, once we have a UML renderer and code dependency visualizer :-) >>> >>> We are currently working on a nice distribution that can be shipped within Pharo 8. >> >> :) >> >> >

April 18, 2019

Re: [Pharo-dev] Roassal Animations

by Mariano Martinez Peck

Yeah I have been following Milton animarioma and they are great! On Wed, Apr 17, 2019, 20:06 Alexandre Bergel via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Hi! > > Just as a follow up, we have a UML diagram builder for Roassal3. > > You can load Roassal3 using: > > Metacello new > baseline: 'Roassal3'; > repository: 'github://ObjectProfile/Roassal3/src'; > load. > > > As indicated on https://github.com/ObjectProfile/Roassal3 > > An UML class diagram can be open using: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | builder pharoClassesToBeVisualized | > > "Zooming and position of the view can be controled using the keys: > I O Space > Arrows > " > > pharoClassesToBeVisualized := > TSAbstractLine > withAllSubclasses. > > builder := > RSUMLClassBuilder > new. > builder classes: pharoClassesToBeVisualized. > > builder classDescriptor > methods: [ :cls | | methods | > methods := cls methods sorted: [ :a :b | > a selector < b selector ] ]. > > builder build. > builder view when: > TSExtentChangedEvent > do: [ builder view zoomToFit ]. > builder open > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > We now do have a support for UML class diagrams and we can easily add new > features, if wanted. > > > Cheers, > Alexandre & Milton > > > On Mar 27, 2019, at 3:37 PM, ducasse <stepharo(a)netcourrier.com> wrote: > > > > On 27 Mar 2019, at 18:27, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > *From: *Alexandre Bergel <alexandre.bergel(a)me.com> > *Subject: **Re: [Pharo-dev] Roassal Animations* > *Date: *27 March 2019 at 18:27:28 CET > *To: *Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Thanks to all of you for your nice words. > These posts are a teaser of what is coming. Code of each animation is part > of Roassal3. Note that we have made no official announcement, simply > because Roassal3 is still well behind Roassal2 in terms of offered > features. Actually, you cannot do much with Roassal3, beside having cool > visualization. > > We will tell you more soon, once we have a UML renderer and code > dependency visualizer :-) > > We are currently working on a nice distribution that can be shipped within > Pharo 8. > > > :) > > > >

April 17, 2019

Re: [Pharo-dev] Roassal Animations

by Alexandre Bergel

Hi! Just as a follow up, we have a UML diagram builder for Roassal3. You can load Roassal3 using: Metacello new baseline: 'Roassal3'; repository: 'github://ObjectProfile/Roassal3/src'; load. As indicated on https://github.com/ObjectProfile/Roassal3 An UML class diagram can be open using: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | builder pharoClassesToBeVisualized | "Zooming and position of the view can be controled using the keys: I O Space Arrows " pharoClassesToBeVisualized := TSAbstractLine withAllSubclasses. builder := RSUMLClassBuilder new. builder classes: pharoClassesToBeVisualized. builder classDescriptor methods: [ :cls | | methods | methods := cls methods sorted: [ :a :b | a selector < b selector ] ]. builder build. builder view when: TSExtentChangedEvent do: [ builder view zoomToFit ]. builder open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= We now do have a support for UML class diagrams and we can easily add new features, if wanted. Cheers, Alexandre & Milton > On Mar 27, 2019, at 3:37 PM, ducasse <stepharo(a)netcourrier.com> wrote: > > > >> On 27 Mar 2019, at 18:27, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> >> From: Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> >> Subject: Re: [Pharo-dev] Roassal Animations >> Date: 27 March 2019 at 18:27:28 CET >> To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >> >> >> Thanks to all of you for your nice words. >> These posts are a teaser of what is coming. Code of each animation is part of Roassal3. Note that we have made no official announcement, simply because Roassal3 is still well behind Roassal2 in terms of offered features. Actually, you cannot do much with Roassal3, beside having cool visualization. >> >> We will tell you more soon, once we have a UML renderer and code dependency visualizer :-) >> >> We are currently working on a nice distribution that can be shipped within Pharo 8. > > :) > >

April 17, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0.3

by Denis Kudriashov

Hi Tim. ÑÐ±, 13 Ð°Ð¿Ñ. 2019 Ð³. Ð² 13:51, Tim Mackinnon <tim(a)testit.works>: > This is great - Iâm pleased we can get fixes like this (and keen to get > passed that font issue which was driving me crazy). > > A small related question - how do ensure we get fixes from sub projects > considered too? Iâd really like to see: > https://github.com/pharo-ide/Calypso/pull/451 as itâs annoying not being > able to move methods between classes. There are a few other Calypso gems in > there too (and quite a few more to fix). > > I worry that having all these sub-projects makes it a bit complicated to > get them included? > Nothing special here. As soon as these projects support old Pharo version it just requires another PR into Pharo 7 with new version of sub-project (modifying loadCalypso in that case). Somebody should just decide that new version needs to be to back ported. > > Tim > > Sent from my iPhone > > On 12 Apr 2019, at 16:26, "tesonep(a)gmail.com" <tesonep(a)gmail.com> wrote: > > Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font > corruption font. > > <image.png> > > Changes Log > > > - #2781 <https://github.com/pharo-project/pharo/pull/2781> Fix comment > on OSWindow >> startTextInput > - #3160 <https://github.com/pharo-project/pharo/pull/3160> > 2975-Problem-when-you-read-an-mcz-pharo7 > - #3130 <https://github.com/pharo-project/pharo/pull/3130> Improving > the performance of SourceFileArray > - #3164 <https://github.com/pharo-project/pharo/pull/3164> MailMessage > can not send mails with attachment in Pharo7 > - #3149 <https://github.com/pharo-project/pharo/pull/3149> > 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat > - #3178 <https://github.com/pharo-project/pharo/pull/3178> Fix for > corrupted fonts in Pharo7 > > Detailed Diff: v7.0.2...pharo-project:v7.0.3 > <https://github.com/pharo-project/pharo/compare/v7.0.2...pharo-project:v7.0.3> > > https://github.com/pharo-project/pharo/releases/tag/v7.0.3 > > All the images are available in ZeroConf and in the Pharo Launcher. > > Thanks to all the collaborators especially: > > - David > - Guille > - Pavel > - Christophe > - Theo > - Sabine > - Sven > > And to all the people that helped to make this release in a couple of > minutes. > And thanks to the academy! > > Pablo > >

April 17, 2019

Handling of deprecation packages

by Torsten Bergmann

Hi, in the past after each release iteration one of the first things applied to a new development image - was to remove the "DeprecatedXX" package of the previous version XX - and add a new "DeprecatedYY" package for the new pharo version YY This allowed then to mark classes that should get obsolete for version YY and put them into "DeprecatedYY" But in current Pharo 8 dev image we still have the "Deprecated70" package inside and a new "Deprecated80" is not yet opened. I know there - were some discussion about having a "migrator" tool first to help in the transition to the new release (but I guess this "migrator" could be written using P7 image, no?) - we can also not just delete "Deprecated70" as StandardFileStream, MultiByteFileStream and others are still useds in the code without giving a proper So I wonder what is the status and on plan this in P8 Thx T.

April 17, 2019

[Pharo 8.0] Build #228: ClassParser: methods polymorphic to RB-nodes for Calypso integration

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #228 was: SUCCESS. The Pull Request #3183 was integrated: "ClassParser: methods polymorphic to RB-nodes for Calypso integration" Pull request url: https://github.com/pharo-project/pharo/pull/3183 Issue Url: https://github.com/pharo-project/pharo/issues/classParserForCalypso Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 17, 2019

Re: [Pharo-dev] ZnMimePart

by Alistair Grant

Hi Sven, On Mon, 15 Apr 2019 at 16:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Alistair, > > Sorry that it took a while to answer, but I did not forget. No problem, I'm a bit behind myself. :-) > > On 17 Mar 2019, at 07:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven, > > > > I'm trying to parse maildir emails using ZnMimePart > > Cool. > > > and have a few questions: > > > > 1. The standard indicates that text lines should be terminated with > > CRLF, however in practice many maildir format emails (as saved by > > offlineimap and successfully handled by mutt) use LF. > > > > Are you open to modifying the parser to be a bit more forgiving, and > > allow CRLF, LF or CR? > > > > I could then completely deprecate MIMEDocument from the image and make > > MailMessage a bit more useful. > > Yes, being more forgiving about line end conventions would not hurt, it is more or less standard practice in Pharo. Just make sure you don't break anything else. I ended up writing a wrapper around the stream that converted random line endings to CRLF. After thinking about it a bit further I actually prefer this approach at the moment. There's a few places in the standard where it is quite specific about how to interpret the various options. Having the wrapper stream isolates the non-standard functionality and allows it to be easily removed. > > 2. ZnStringEntity and ZnByteArrayEntity both appear to answer their > > contents without decoding the data based on the > > Content-Transfer-Encoding, e.g. if I have: > > > > Date: Sat, 16 Mar 2019 12:00:21 +0100 > > MIME-Version: 1.0 > > Content-Type: image/jpeg; name="00585-capture.jpg" > > Content-Transfer-Encoding: base64 > > Content-Disposition: inline; filename="00585-capture.jpg" > > > > base64dataincludedhere... > > > > and send: > > > > aZmMimePart contents > > > > I'll get back the the result of evaluating: > > > > 'base64dataincludedhere...' asByteArray > > > > instead of the decoded data. > > > > Is this intended? I'd expect the decoded data (with charset decoding as > > well, in the case of text). > > I am not sure I fully understand: both ZnStringEntity>>#contents and ZnByteArrayEntity>>#contents clearly return the internal string or bytes, so the fully decoded data. > > A ZnMimePart considers its entity to be its contents. > > The handling of transfer headers is currently located outside these objects, ZnEntityReader and ZnEntityWriter, as far as I remember. This feels correct. I'll have to get back to this. I'm side-tracked on other stuff at the moment, but thanks for your explanation. > > 3. What do you think of adding a few convenience test methods, e.g. > > isImage, isApplication, isText, etc.? > > That would be OK I guess. An alternative would be to add them to ZnMimeType, then more clients could use them (as far as they are universal enough). Great. I'll get around to tidying up my modifications and submit them as a few PRs. P.S. I've successfully scanned about 35,000 emails. Thanks again, Alistair

April 16, 2019

[Pharo 8.0] Build #227: Make size_t work inside a nested structure

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #227 was: SUCCESS. The Pull Request #3142 was integrated: "Make size_t work inside a nested structure" Pull request url: https://github.com/pharo-project/pharo/pull/3142 Issue Url: https://github.com/pharo-project/pharo/issues/ffi Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 16, 2019

[Pharo 8.0] Build #226: 3188-Some-classes-have-an-users-property

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #226 was: SUCCESS. The Pull Request #3190 was integrated: "3188-Some-classes-have-an-users-property" Pull request url: https://github.com/pharo-project/pharo/pull/3190 Issue Url: https://github.com/pharo-project/pharo/issues/3188 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 16, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0.3

by Tim Mackinnon

FYI - I was able to confirm that my working 703 image continues to show the issue (Exercism+Mirage seem to cause it - but I suspect itâs Mirage rendering thumbnails in multiple threads that stresses things). Guille has come up with a filein that has some more aggressive mutex code (from my quick glance), so I am running with that to see if I can empirically show it helps. Tim Sent from my iPhone > On 16 Apr 2019, at 08:30, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi tim > > I think that this is better to create a new issue. > > Stef > > >> On 15 Apr 2019, at 09:57, Tim Mackinnon <tim(a)testit.works> wrote: >> >> No problem - itâs a bit early to tell if itâs the same as before - my sense is that itâs slightly improved. I had that 7.0.3 image in light use for 3-4 hours before I noticed it. In 7.0.2 it would happen within 5-20 mins. >> >> I deliberately loaded Mirage as I recalled it was the catalyst before, and I think this might still be the case - but Iâll continue to use this setup to give more details. >> >> Do we re-open the previous issue and our feedback there? >> >> Tim >> >> Sent from my iPhone >> >>> On 15 Apr 2019, at 08:14, "tesonep(a)gmail.com" <tesonep(a)gmail.com> wrote: >>> >>> I am afraid we will need to give more love to it. >>> We need a proper solution, hacking it is not working. We will have to refactor implementation and modify the users. >>> It is not that we are lazy (that we are) but also it is ugly and full of magic numbers. >>> >>> But we will win, we must win! >>> >>> Thanks again for the report! >>> >>>> On Mon, Apr 15, 2019 at 9:10 AM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: >>>> Thanks a lot, founding the issue is important. >>>> For sure I missed some other users of freetype doing the same!! >>>> >>>>> On Mon, Apr 15, 2019 at 1:14 AM Tim Mackinnon <tim(a)testit.works> wrote: >>>>> I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font glyph issue (see how my menus have started to go) - saving my image has fixed it (for now). I do have Mirage loaded in my image ( the latest version, and I was showing you guys how that seems to stress it a bit more). >>>>> >>>>> Tim >>>>> >>>>> <PastedGraphic-8.png> >>>>> >>>>> >>>>> <PastedGraphic-9.png> >>>>> >>>>>> On 14 Apr 2019, at 15:16, tesonep(a)gmail.com wrote: >>>>>> >>>>>> Like in the Oscars, I was thanking everybody. ;) >>>>>> >>>>>> On Fri, 12 Apr 2019, 21:40 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr wrote: >>>>>>> what is the academy? >>>>>>> :) >>>>>>> >>>>>>> stef >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 12 Apr 2019, at 17:26, tesonep(a)gmail.com wrote: >>>>>>>> >>>>>>>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font corruption font. >>>>>>>> >>>>>>>> <image.png> >>>>>>>> >>>>>>>> Changes Log >>>>>>>> >>>>>>>> #2781 Fix comment on OSWindow >> startTextInput >>>>>>>> #3160 2975-Problem-when-you-read-an-mcz-pharo7 >>>>>>>> #3130 Improving the performance of SourceFileArray >>>>>>>> #3164 MailMessage can not send mails with attachment in Pharo7 >>>>>>>> #3149 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat >>>>>>>> #3178 Fix for corrupted fonts in Pharo7 >>>>>>>> Detailed Diff: v7.0.2...pharo-project:v7.0.3 >>>>>>>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3 >>>>>>>> >>>>>>>> All the images are available in ZeroConf and in the Pharo Launcher. >>>>>>>> >>>>>>>> Thanks to all the collaborators especially: >>>>>>>> >>>>>>>> - David >>>>>>>> - Guille >>>>>>>> - Pavel >>>>>>>> - Christophe >>>>>>>> - Theo >>>>>>>> - Sabine >>>>>>>> - Sven >>>>>>>> >>>>>>>> And to all the people that helped to make this release in a couple of minutes. >>>>>>>> And thanks to the academy! >>>>>>>> >>>>>>>> Pablo >>>>>>> >>>>>>> -------------------------------------------- >>>>>>> StÃ©phane Ducasse >>>>>>> http://stephane.ducasse.free.fr >>>>>>> http://www.synectique.eu / http://www.pharo.org >>>>>>> 03 59 35 87 52 >>>>>>> Assistant: Julie Jonas >>>>>>> FAX 03 59 57 78 50 >>>>>>> TEL 03 59 35 86 16 >>>>>>> S. Ducasse - Inria >>>>>>> 40, avenue Halley, >>>>>>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>>>>>> Villeneuve d'Ascq 59650 >>>>>>> France >>>>>>> >>>>> >>>> >>>> >>>> -- >>>> Pablo Tesone. >>>> tesonep(a)gmail.com >>> >>> >>> -- >>> Pablo Tesone. >>> tesonep(a)gmail.com >

April 16, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0.3

by ducasse

Hi tim I think that this is better to create a new issue. Stef > On 15 Apr 2019, at 09:57, Tim Mackinnon <tim(a)testit.works> wrote: > > No problem - itâs a bit early to tell if itâs the same as before - my sense is that itâs slightly improved. I had that 7.0.3 image in light use for 3-4 hours before I noticed it. In 7.0.2 it would happen within 5-20 mins. > > I deliberately loaded Mirage as I recalled it was the catalyst before, and I think this might still be the case - but Iâll continue to use this setup to give more details. > > Do we re-open the previous issue and our feedback there? > > Tim > > Sent from my iPhone > > On 15 Apr 2019, at 08:14, "tesonep(a)gmail.com <mailto:tesonep@gmail.com>" <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> wrote: > >> I am afraid we will need to give more love to it. >> We need a proper solution, hacking it is not working. We will have to refactor implementation and modify the users. >> It is not that we are lazy (that we are) but also it is ugly and full of magic numbers. >> >> But we will win, we must win! >> >> Thanks again for the report! >> >> On Mon, Apr 15, 2019 at 9:10 AM tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> wrote: >> Thanks a lot, founding the issue is important. >> For sure I missed some other users of freetype doing the same!! >> >> On Mon, Apr 15, 2019 at 1:14 AM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font glyph issue (see how my menus have started to go) - saving my image has fixed it (for now). I do have Mirage loaded in my image ( the latest version, and I was showing you guys how that seems to stress it a bit more). >> >> Tim >> >> <PastedGraphic-8.png> >> >> >> <PastedGraphic-9.png> >> >>> On 14 Apr 2019, at 15:16, tesonep(a)gmail.com <mailto:tesonep@gmail.com> wrote: >>> >>> Like in the Oscars, I was thanking everybody. ;) >>> >>> On Fri, 12 Apr 2019, 21:40 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr> wrote: >>> what is the academy? >>> :) >>> >>> stef >>> >>> >>> >>>> On 12 Apr 2019, at 17:26, tesonep(a)gmail.com <mailto:tesonep@gmail.com> wrote: >>>> >>>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font corruption font. >>>> >>>> <image.png> >>>> >>>> Changes Log >>>> >>>> #2781 <https://github.com/pharo-project/pharo/pull/2781> Fix comment on OSWindow >> startTextInput >>>> #3160 <https://github.com/pharo-project/pharo/pull/3160> 2975-Problem-when-you-read-an-mcz-pharo7 >>>> #3130 <https://github.com/pharo-project/pharo/pull/3130> Improving the performance of SourceFileArray >>>> #3164 <https://github.com/pharo-project/pharo/pull/3164> MailMessage can not send mails with attachment in Pharo7 >>>> #3149 <https://github.com/pharo-project/pharo/pull/3149> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat >>>> #3178 <https://github.com/pharo-project/pharo/pull/3178> Fix for corrupted fonts in Pharo7 >>>> Detailed Diff: v7.0.2...pharo-project:v7.0.3 <https://github.com/pharo-project/pharo/compare/v7.0.2...pharo-project:v7.0.3> >>>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3 <https://github.com/pharo-project/pharo/releases/tag/v7.0.3> >>>> All the images are available in ZeroConf and in the Pharo Launcher. >>>> >>>> Thanks to all the collaborators especially: >>>> >>>> - David >>>> - Guille >>>> - Pavel >>>> - Christophe >>>> - Theo >>>> - Sabine >>>> - Sven >>>> >>>> And to all the people that helped to make this release in a couple of minutes. >>>> And thanks to the academy! >>>> >>>> Pablo >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> >>> http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <http://www.pharo.org/> >>> 03 59 35 87 52 >>> Assistant: Julie Jonas >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >> >> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com <mailto:tesonep@gmail.com> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com <mailto:tesonep@gmail.com>

April 16, 2019

Re: [Pharo-dev] MQTT Data Broker & Client in Smalltalk

by ducasse

I like to see tests there :) Iâm trying to write tests for the sound package and this is an kind of strange exercise. Stef > On 16 Apr 2019, at 09:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 16 Apr 2019, at 08:10, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Thanks John >> >> Great news. >> Do you know how different it is from https://github.com/svenvc/mqtt. >> I saw that Sven have some tests. I did not see if he has the server part. > > Yes, that is correct: what I once did was a new MQTT client, an MQTT broker is a server that manages the distribution of messages. > >> Stef >> >> >> >>> On 16 Apr 2019, at 04:00, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: >>> >>> Today we are pushing out a MQTT V311 client and data broker we've written in pure smalltalk. It is based on Tim Rowledge's earlier work, but as far as I know the only data broker in smalltalk. >>> >>> https://github.com/LabWare/MQTT-broker >>> >>> .... >>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk >>> >>> >> > >

April 16, 2019