- Pharo-dev - lists.pharo.org

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

by ducasse

We will certainly back port the font glitches in P7.0 because it is important. Stef > On 18 Apr 2019, at 14:54, Tim Mackinnon <tim(a)testit.works> wrote: > > >> On 17 Apr 2019, at 23:43, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@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 19, 2019

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

by phil＠highoctane.be

Question: Can't we use some platform facility for renderering text on a surface instead of using FreeType? e.g. Windows https://docs.microsoft.com/en-us/windows/desktop/direct2d/direct2d-and-dire… Phil <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Garanti sans virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Apr 19, 2019 at 12:12 PM Tim Mackinnon <tim(a)testit.works> wrote: > > 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 19, 2019

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

by Serge Stinckwich

done : https://github.com/pillar-markup/pillar/issues/368 On Thu, Apr 18, 2019 at 4:15 PM ducasse <stepharo(a)netcourrier.com> wrote: > 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> 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 > > > -- 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 19, 2019

Re: [Pharo-dev] Handling of deprecation packages

by Stephan Eggermont

Torsten Bergmann <astares(a)gmx.de> wrote: > 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. There are indeed several open issues with the new streams usage. I posted one on the handling of filing in fileouts by drag and drop. The issue I see with existing code is mostly that an object is used as a stream but is actually an information holder which understands much more than the stream protocol. Rewriting that code to use a streamHolder can be non-trivial. The fallback behavior of a readWriteStream opened on a read-only file is also not easy to get right. Stephan

April 19, 2019

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

by Esteban Lorenzano

yep. The Pharo distribution uses install_name_tool to deal with it, if you want an example already in osvm code: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64…> Esteban > On 18 Apr 2019, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@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://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e4…> > https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath <https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath> > > _,,,^..^,,,_ > best, Eliot

April 19, 2019

Re: [Pharo-dev] Handling of deprecation packages

by Christopher Fuhrman

Hello all, Apologies if I am on the wrong page.... On Thu, Apr 18, 2019, 09:26 Torsten Bergmann <astares(a)gmx.de> wrote: > 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. > The following guide was useful to me: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/Migratio…

April 19, 2019

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

by Ben Coman

On Fri, 19 Apr 2019 at 01:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 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 Interesting reading. thx for the links. cheers -ben

April 19, 2019

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