- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Off Topic] Michel Bauwens on the history and immediate future of work

by ducasse

Thanks we will watch it > On 25 Jan 2019, at 17:41, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi All, > > I find this talk profound and key to making functional open source communities as we try and survive. > > Iâve skipped an introduction in Portuguese and some slide control issues. > https://youtu.be/vDjazcMm-eE?t=4m40s <https://youtu.be/vDjazcMm-eE?t=4m40s> > _,,,^..^,,,_ (phone)

Jan. 26, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

by ducasse

Hello > > Torsten Bergmann wrote >> We have a large community with many, many users - but still only a few >> contribute to the core system. >> >> I wonder why and would like to know: >> - Is it due to the switch to git ? >> - Is is due to the new contribution process? >> - Is it for other reasons? > > For me; a combination of 1 and 2. > I've done work in Pharo 6.1 during the Pharo7 process, but had no idea how > to easily forward-port any base fixes to Pharo 7. The times I tried (after a > good old-fashioned file-out), I failed to get Iceberg check out Pharo7 on > Windows. > IIRC, I believe I resorted to posting an .st in the issues (which then timed > out after a year of being stuck in for review status with no automatical > validation) > As such, I'm absent from the contributor list for the first time since... > Pharo 1.1? ;) > > I hope switching to Pharo8 branch and commiting fixes while working in > Pharo7 will be easier? I can tell you. It is a **lot** easier can you tell us if the following is understandable for you https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 26, 2019

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

by ducasse

Now github. Stef > On 24 Jan 2019, at 20:44, Eric Gade <eric.gade(a)gmail.com> wrote: > > Which is now the canonical place to seek out these issues/bugs: manuscript or GitHub? > > On Thu, Jan 24, 2019, 14:37 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de> wrote: > Hi, > > it's a nice release yes - and the best we ever provided indeed. I'm really happy too that P7 image is an > official release now. > > > But still: > ========== > > In a post [1] in November 2017 I brought up the topic again to "increase the quality level in Pharo 7 and onwards". > > With 762 commits [2] for Pharo 7 I devoted a lot of time in fixing often simple and trivial things just to clean up > comments, code, typos, packages, manifests, tests and so on. > > Many others did the same and supported these cleaning efforts. This helped adding a few more release tests to keep the > quality bar on the level reached. Special thanks to Marcus, Esteban, and many others who helped reviewing, fighting a > shaky CI server, integrating quickly and so on ... > > Still THIS IS NOT FINISHED ... and it would be really help if more people would participate in the cleaning or fixing bugs. > Also many external packages now need some love to work with Pharo 7. > > We have a large community with many, many users - but still only a few contribute to the core system. > > I wonder why and would like to know: > - Is it due to the switch to git ? > - Is is due to the new contribution process? > - Is it for other reasons? > > Remember: Pharo is yours and even small steps could make a difference. So please join! > > Thanks > T. > > > [1] http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-an… <http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-an…> > [2] https://github.com/pharo-project/pharo/graphs/contributors <https://github.com/pharo-project/pharo/graphs/contributors> > >

Jan. 26, 2019

Re: [Pharo-dev] naming convention for pharo-vm/lib/pharo/* directory?

by Dale Henrichs

Thanks, Nicolas (and Sven), VM search path is what I am looking for (UFFI external modules) and I am curious whether or not this path `pharo-vm/lib/pharo/5.0-201806281256` is constant or variable for the various Pharo versions or does it vary based on the vm version/build number ... pharo6.0 and pharo.1 appear to have the same path ... haven't looked at Pharo7.0 ... and hopefully the path is the same for mac and unix or does it vary ... I don't have a mac to readily test on:) The bash script that copies my unix/mac .so/.dylib files will be run immediately after the image and vm have been downloaded so I won't be running the image itself (unless I have to). Currently, the download, installation and build of the pharo client for GemStone is built by a bash script... I'm going to assume for now that the gci libraries will be shoveled into the pharo-vm/lib/5.0-* directory until someone gives me a more definitive answer... Dale On 1/25/19 12:27 PM, Nicolas Cellier wrote: > Oh, maybe you're after PharoLauncher conventions? > I was talking of underlying VM search path. > I remember that the library loading happens in ioLoadModule() both for > FFI and external plugins. > https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=ioLoadModule&uns… > > LeÂ ven. 25 janv. 2019 Ã Â 18:45, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> a Ã©critÂ : > > Maybe FileLocator can help ? > > on macOS > > FileLocator vmDirectory pathString. > "'/Users/sven/Develop/Pharo/Pharo-Daily/2019-01-24/pharo-vm'" > > FileLocator vmBinary pathString. > "'/Users/sven/Develop/Pharo/Pharo-Daily/2019-01-24/pharo-vm/Pharo.app/Contents/MacOS/Pharo'" > > on Linux > > $ ../bin/pharo Pharo.image eval 'FileLocator vmDirectory pathString' > '/home/t3/pharo/bin/pharo-vm' > > $ ../bin/pharo Pharo.image eval 'FileLocator vmBinary pathString' > '/home/t3/pharo/bin/pharo-vm/pharo' > > > On 25 Jan 2019, at 18:25, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > > Thanks Nicolas, > > > > Is it as simple as pharo/*, or could there be multiple > directories created and I need to pick the right one? > > > > Dale > > > > On 1/25/19 12:48 AM, Nicolas Cellier wrote: > >> I'm afraid it also depends on the overly complex rules burried > deep inside the VM... > >> It would be a good thing to try and document it. > >> And if we can't reasonably document it, then we might want to > open an issue on opensmalltalk. > >> > >> Le ven. 25 janv. 2019 Ã 01:51, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> a Ã©crit : > >> I am in the process of porting the GemStone-GCI[1] project to > Pharo6.1 > >> (32 bit) and Pharo7.0 (64 bit) and I'm curious what the naming > >> convention for the library directories are. > >> > >> For Pharo5.0 and earlier, I copied my 32 bit gemstone gci > library files > >> (.so on linux) into the pharo-vm directory. > >> > >> For Pharo6.1 I just figured out that I need to copy the gci > library > >> files into the pharo-vm/lib/pharo/5.0-201806281256 directory > ... at list > >> the libraries are found when I do so? > >> > >> I would like to be able to write a bash script that copies the gci > >> library files into the proper directory, but the directory for the > >> Pharo6.1 vm looks like some kind of magic number and I assume that > >> different builds of the 6.1 vm could have different names and > possibly > >> even multiple directories under pharo-vm/lib/pharo/? > >> > >> I haven't looked at Pharo7.0 yet to see what it's pharo-vm > directory > >> structure looks like... > >> > >> A pointer to where the naming conventions for these directories is > >> described for Pharo6.x, Pharo7.x and Pharo8.x would be greatly > >> appreciated ... would also be nice if the error message for the > "module > >> not found" error could be a bit more descriptive as well ... > >> > >> Thanks, > >> > >> Dale > >> > >> [1] https://github.com/GsDevKit/GemStone-GCI > >> > >> > >

Jan. 25, 2019

Re: [Pharo-dev] naming convention for pharo-vm/lib/pharo/* directory?

by Nicolas Cellier

Oh, maybe you're after PharoLauncher conventions? I was talking of underlying VM search path. I remember that the library loading happens in ioLoadModule() both for FFI and external plugins. https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=ioLoadModule&uns… Le ven. 25 janv. 2019 Ã 18:45, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > Maybe FileLocator can help ? > > on macOS > > FileLocator vmDirectory pathString. > "'/Users/sven/Develop/Pharo/Pharo-Daily/2019-01-24/pharo-vm'" > > FileLocator vmBinary pathString. > > "'/Users/sven/Develop/Pharo/Pharo-Daily/2019-01-24/pharo-vm/Pharo.app/Contents/MacOS/Pharo'" > > on Linux > > $ ../bin/pharo Pharo.image eval 'FileLocator vmDirectory pathString' > '/home/t3/pharo/bin/pharo-vm' > > $ ../bin/pharo Pharo.image eval 'FileLocator vmBinary pathString' > '/home/t3/pharo/bin/pharo-vm/pharo' > > > On 25 Jan 2019, at 18:25, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > > > > Thanks Nicolas, > > > > Is it as simple as pharo/*, or could there be multiple directories > created and I need to pick the right one? > > > > Dale > > > > On 1/25/19 12:48 AM, Nicolas Cellier wrote: > >> I'm afraid it also depends on the overly complex rules burried deep > inside the VM... > >> It would be a good thing to try and document it. > >> And if we can't reasonably document it, then we might want to open an > issue on opensmalltalk. > >> > >> Le ven. 25 janv. 2019 Ã 01:51, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> a Ã©crit : > >> I am in the process of porting the GemStone-GCI[1] project to Pharo6.1 > >> (32 bit) and Pharo7.0 (64 bit) and I'm curious what the naming > >> convention for the library directories are. > >> > >> For Pharo5.0 and earlier, I copied my 32 bit gemstone gci library files > >> (.so on linux) into the pharo-vm directory. > >> > >> For Pharo6.1 I just figured out that I need to copy the gci library > >> files into the pharo-vm/lib/pharo/5.0-201806281256 directory ... at > list > >> the libraries are found when I do so? > >> > >> I would like to be able to write a bash script that copies the gci > >> library files into the proper directory, but the directory for the > >> Pharo6.1 vm looks like some kind of magic number and I assume that > >> different builds of the 6.1 vm could have different names and possibly > >> even multiple directories under pharo-vm/lib/pharo/? > >> > >> I haven't looked at Pharo7.0 yet to see what it's pharo-vm directory > >> structure looks like... > >> > >> A pointer to where the naming conventions for these directories is > >> described for Pharo6.x, Pharo7.x and Pharo8.x would be greatly > >> appreciated ... would also be nice if the error message for the "module > >> not found" error could be a bit more descriptive as well ... > >> > >> Thanks, > >> > >> Dale > >> > >> [1] https://github.com/GsDevKit/GemStone-GCI > >> > >> > > >

Jan. 25, 2019

Re: [Pharo-dev] naming convention for pharo-vm/lib/pharo/* directory?

by Sven Van Caekenberghe

Maybe FileLocator can help ? on macOS FileLocator vmDirectory pathString. "'/Users/sven/Develop/Pharo/Pharo-Daily/2019-01-24/pharo-vm'" FileLocator vmBinary pathString. "'/Users/sven/Develop/Pharo/Pharo-Daily/2019-01-24/pharo-vm/Pharo.app/Contents/MacOS/Pharo'" on Linux $ ../bin/pharo Pharo.image eval 'FileLocator vmDirectory pathString' '/home/t3/pharo/bin/pharo-vm' $ ../bin/pharo Pharo.image eval 'FileLocator vmBinary pathString' '/home/t3/pharo/bin/pharo-vm/pharo' > On 25 Jan 2019, at 18:25, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Thanks Nicolas, > > Is it as simple as pharo/*, or could there be multiple directories created and I need to pick the right one? > > Dale > > On 1/25/19 12:48 AM, Nicolas Cellier wrote: >> I'm afraid it also depends on the overly complex rules burried deep inside the VM... >> It would be a good thing to try and document it. >> And if we can't reasonably document it, then we might want to open an issue on opensmalltalk. >> >> Le ven. 25 janv. 2019 Ã 01:51, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> a Ã©crit : >> I am in the process of porting the GemStone-GCI[1] project to Pharo6.1 >> (32 bit) and Pharo7.0 (64 bit) and I'm curious what the naming >> convention for the library directories are. >> >> For Pharo5.0 and earlier, I copied my 32 bit gemstone gci library files >> (.so on linux) into the pharo-vm directory. >> >> For Pharo6.1 I just figured out that I need to copy the gci library >> files into the pharo-vm/lib/pharo/5.0-201806281256 directory ... at list >> the libraries are found when I do so? >> >> I would like to be able to write a bash script that copies the gci >> library files into the proper directory, but the directory for the >> Pharo6.1 vm looks like some kind of magic number and I assume that >> different builds of the 6.1 vm could have different names and possibly >> even multiple directories under pharo-vm/lib/pharo/? >> >> I haven't looked at Pharo7.0 yet to see what it's pharo-vm directory >> structure looks like... >> >> A pointer to where the naming conventions for these directories is >> described for Pharo6.x, Pharo7.x and Pharo8.x would be greatly >> appreciated ... would also be nice if the error message for the "module >> not found" error could be a bit more descriptive as well ... >> >> Thanks, >> >> Dale >> >> [1] https://github.com/GsDevKit/GemStone-GCI >> >>

Jan. 25, 2019

Re: [Pharo-dev] naming convention for pharo-vm/lib/pharo/* directory?

by Dale Henrichs

Thanks Nicolas, Is it as simple as pharo/*, or could there be multiple directories created and I need to pick the right one? Dale On 1/25/19 12:48 AM, Nicolas Cellier wrote: > I'm afraid it also depends on the overly complex rules burried deep > inside the VM... > It would be a good thing to try and document it. > And if we can't reasonably document it, then we might want to open an > issue on opensmalltalk. > > LeÂ ven. 25 janv. 2019 Ã Â 01:51, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> a Ã©critÂ : > > I am in the process of porting the GemStone-GCI[1] project to > Pharo6.1 > (32 bit) and Pharo7.0 (64 bit) and I'm curious what the naming > convention for the library directories are. > > For Pharo5.0 and earlier, I copied my 32 bit gemstone gci library > files > (.so on linux) into the pharo-vm directory. > > For Pharo6.1 I just figured out that I need to copy the gci library > files into the pharo-vm/lib/pharo/5.0-201806281256 directory ... > at list > the libraries are found when I do so? > > I would like to be able to write a bash script that copies the gci > library files into the proper directory, but the directory for the > Pharo6.1 vm looks like some kind of magic number and I assume that > different builds of the 6.1 vm could have different names and > possibly > even multiple directories under pharo-vm/lib/pharo/? > > I haven't looked at Pharo7.0 yet to see what it's pharo-vm directory > structure looks like... > > A pointer to where the naming conventions for these directories is > described for Pharo6.x, Pharo7.x and Pharo8.x would be greatly > appreciated ... would also be nice if the error message for the > "module > not found" error could be a bit more descriptive as well ... > > Thanks, > > Dale > > [1] https://github.com/GsDevKit/GemStone-GCI > >

Jan. 25, 2019

[Off Topic] Michel Bauwens on the history and immediate future of work

by Eliot Miranda

Hi All, I find this talk profound and key to making functional open source communities as we try and survive. Iâve skipped an introduction in Portuguese and some slide control issues. https://youtu.be/vDjazcMm-eE?t=4m40s _,,,^..^,,,_ (phone)

Jan. 25, 2019

Re: [Pharo-dev] [Pharo-users] macOS VM builds with AddressSanitizer/LeakSanitizer

by Manuel Leuenberger

Hi Ben, Thanks for the pointer, I subscribed to those two mailing lists as well. Cheers, Manuel > On 25 Jan 2019, at 14:25, Ben Coman <btc(a)openinworld.com> wrote: > > Hi Manuel, > > This level question would be better handled on pharo-dev and vm-dev mail lists (forwarded a copy). > http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org <http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org> > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev> > > On Fri, 25 Jan 2019 at 16:09, Manuel Leuenberger <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>> wrote: > Hi, > > Anybody has experience building the VM (pharo.cog.spur) on macOS with custom compiler and flags? > > I am observing a memory leak on macOS Sierra/Pharo 7/GToolkit. I cannot precisely locate the issue, e.g. I cannot reliably reproduce the problem. So I tried to use AddressSanitizer/LeakSanitizer with custom debug builds of the VM and libMoz2D (used by GToolkit). As building on Linux is easier than on macOS, I got myself some help from a colleague and we managed to build those two artifacts on Linux by sprinkling "-g3 -O0 -fsanitize=leak -fsanitize-memory-track-origins" into the CFLAGS wherever they appear or are picked up. This works fine on Debian 9 with "CC=clang-6.0 CXX=clang++-6.0 ./mvm -d" and some on-the-fly patches for other breaking things. > > Unfortunately, I cannot reproduce the problem on Linux, so it seems to be platform specific. Even more so, I seem to be the only one observing the issue. Other GToolkit users do not report this issue. As these kind of issues are freaking me out, I cannot let go and need to learn what causes them. So, here I am, trying to build the VM on macOS Sierra and miserably failing to include the sanitizer tags with Clang and giving me those tasty leak reports on VM shutdown. > > The leak is not observable in the image memory, i.e. the image size reported by the VM is not growing, I am suspecting FFI, possibly in Moz2D, to leak. > The FFI registry in the VM also does not report many or large surviving objects, so I would assume the problem to be either on the plugin or VM side. > > My two concrete questions are: > 1. Is it even feasible to detect leaks with this approach? E.g., how does the VM behave on shutdown? Will the leaks show up in the report or will they not be covered, as the VM actually frees everything before shutting down? > 2. How do I swap compiler and inject flags on macOS builds? On Linux it was fairly easily done by replacing some variables. But on macOS, Xcode seems to like to mess with me. I got myself Clang-6.0 on macOS from MacPorts, the same as version as I took on Linux. I can build the VM with this, but it there is no leak report on VM shutdown. Anybody has an idea how to debug the build? > > Bonus question: Can the VM provide an inspectable view of all the allocated memory to the image? That would be perfect. I think Luke Gorrie does some magic like this in his Studio for core dumps etc. > > Cheers, > Manuel > >

Jan. 25, 2019

Re: [Pharo-dev] [Pharo-users] macOS VM builds with AddressSanitizer/LeakSanitizer

by Ben Coman

Hi Manuel, This level question would be better handled on pharo-dev and vm-dev mail lists (forwarded a copy). http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org http://lists.squeakfoundation.org/mailman/listinfo/vm-dev On Fri, 25 Jan 2019 at 16:09, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > Hi, > > Anybody has experience building the VM (pharo.cog.spur) on macOS with > custom compiler and flags? > > I am observing a memory leak on macOS Sierra/Pharo 7/GToolkit. I cannot > precisely locate the issue, e.g. I cannot reliably reproduce the problem. > So I tried to use AddressSanitizer/LeakSanitizer with custom debug builds > of the VM and libMoz2D (used by GToolkit). As building on Linux is easier > than on macOS, I got myself some help from a colleague and we managed to > build those two artifacts on Linux by sprinkling "-g3 -O0 -fsanitize=leak > -fsanitize-memory-track-origins" into the CFLAGS wherever they appear or > are picked up. This works fine on Debian 9 with "CC=clang-6.0 > CXX=clang++-6.0 ./mvm -d" and some on-the-fly patches for other breaking > things. > > Unfortunately, I cannot reproduce the problem on Linux, so it seems to be > platform specific. Even more so, I seem to be the only one observing the > issue. Other GToolkit users do not report this issue. As these kind of > issues are freaking me out, I cannot let go and need to learn what causes > them. So, here I am, trying to build the VM on macOS Sierra and miserably > failing to include the sanitizer tags with Clang and giving me those tasty > leak reports on VM shutdown. > > The leak is not observable in the image memory, i.e. the image size > reported by the VM is not growing, I am suspecting FFI, possibly in Moz2D, > to leak. > The FFI registry in the VM also does not report many or large surviving > objects, so I would assume the problem to be either on the plugin or VM > side. > > My two concrete questions are: > 1. Is it even feasible to detect leaks with this approach? E.g., how does > the VM behave on shutdown? Will the leaks show up in the report or will > they not be covered, as the VM actually frees everything before shutting > down? > 2. How do I swap compiler and inject flags on macOS builds? On Linux it > was fairly easily done by replacing some variables. But on macOS, Xcode > seems to like to mess with me. I got myself Clang-6.0 on macOS from > MacPorts, the same as version as I took on Linux. I can build the VM with > this, but it there is no leak report on VM shutdown. Anybody has an idea > how to debug the build? > > Bonus question: Can the VM provide an inspectable view of all the > allocated memory to the image? That would be perfect. I think Luke Gorrie > does some magic like this in his Studio for core dumps etc. > > Cheers, > Manuel > > >

Jan. 25, 2019