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

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

by John M McIntosh

Tim wrote a few tests, some of that support is in this code. No SUnits tho. What I did instead was rely on tests other people did to check for compliance to the specification for both the Client and Server in various language, Perl or Python. As we are providing a client or a server component it is 'easy' to drive other people's spec tests to the unix socket. .... John M. McIntosh. Corporate Smalltalk Consulting LtdÂ https://www.linkedin.com/in/smalltalk âââââââ Original Message âââââââ On Tuesday, April 16, 2019 12:28 AM, ducasse <stepharo(a)netcourrier.com> wrote: > 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 18, 2019

Re: [Pharo-dev] Any experts on using path in app bundles willing to help me?

by Eliot Miranda

On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > I have a plugin dependent on several support libraries that may be > shared with other plugins. So I want the support libraries in a common > place (TheVm.app/Contents/Frameworks) while the plugins themselves are > bundles in TheVM.app/Contents/Resources. In allowing one to install plugin > support libraries in TheVM.app/Contents/Frameworks I have to use the > linker's -rpath feature to specify where dlopen may find the search > libraries. The question i don't see an answer to in Apple's documentation > is whether one uses -rpath when linking the plugin, or when linking the VM > into which the plugin will be loaded, or both. Anybody ever done this and > know definitively what to do? > Never mind. I think I've found what I need: https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4… https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath _,,,^..^,,,_ best, Eliot

April 18, 2019

Any experts on using path in app bundles willing to help me?

by Eliot Miranda

Hi All, I have a plugin dependent on several support libraries that may be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do? _,,,^..^,,,_ best, Eliot

April 18, 2019

Re: [Pharo-dev] Roassal Animations

by Alexandre Bergel

Yes, that is the idea Alexandre > On Apr 18, 2019, at 1:42 AM, 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] Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"

by ducasse

Hi serge I cannot check now but Pillar should be running in P7 64 bits without problem. I see many warnings too. Can you open a bug entry? Stef > On 18 Apr 2019, at 15:48, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > 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 <mailto:serge.stinckwich@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 <mailto:estebanlm@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 <mailto:sven@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 Stinckwich > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University (SU) > French National Research Institute for Sustainable Development (IRD) > University of YaoundÃ© I, Cameroun > "Programs must be written for people to read, and only incidentally for machines to execute." > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich>

April 18, 2019

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