March 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #661: 21327-Integrate-the-new-version-of-Modular-Stateful-Traits

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

There is a new Pharo build available! The status of the build #661 was: SUCCESS. The Pull Request #871 was integrated: "21327-Integrate-the-new-version-of-Modular-Stateful-Traits" Pull request url: https://github.com/pharo-project/pharo/pull/871 Issue Url: https://pharo.fogbugz.com/f/cases/21327 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 7, 2018

Re: [Pharo-dev] Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by David T. Lewis

On Tue, Mar 06, 2018 at 11:49:14AM +0100, Sabine Manaa wrote: > Hi, > > I can report the following: > > The problem with the Buffer overflow remains also with OSProcess. > Also with the normal vm (https://get.pharo.org ). > > Summary: I have buffer overflow crashes with my application on Linux. > The same code runs without problems on MacOS and on Windows. > I have the same test data/database and do exactly the same. > > The problem occurs only after calling several times OSProcess/OSSubprocess. > This is the reason why I first had a suspicion that OSSubprocess is > responsible for the crashes. > > Can anyone tell me how to proceed to find the reason for the buffer > overflow? > There is no PharoDebug.log > > Help is very appreciated! > > This is the message when terminating: > > root@Pharo_ubuntu_16:/spf/build# ./pharo Pharo-Productive-SPF.image > --no-quit > > SmalltalkImageInstanceID class>>startUp*** buffer overflow detected ***: > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated > What is class SmalltalkImageInstanceID? I have a Pharo 6.1 image, and I am running on Ubuntu. I loaded OSProcess to check this out, but I am not sure what that #startUp message is doing. Thanks, Dave

March 7, 2018

Re: [Pharo-dev] PharoDays?

by Myroslava Romaniuk

What about sometime mid-May? On 28 February 2018 at 19:10, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Or 24-25 of May > Or 31 - 1 June? > > On Wed, Feb 28, 2018 at 6:09 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > Hi guys > > > > many people are asking when and where there will be PharoDays. > > And we do not know. > > We are looking for local organisers and else we do it at Lille. > > Now what would be a good date? > > > > What about > > 7-8 June? > > > > Stef > > -- Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

March 6, 2018

[Pharo 7.0-dev] Build #660: 21508-Integrate-Calypso-0103

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

There is a new Pharo build available! The status of the build #660 was: SUCCESS. The Pull Request #1037 was integrated: "21508-Integrate-Calypso-0103" Pull request url: https://github.com/pharo-project/pharo/pull/1037 Issue Url: https://pharo.fogbugz.com/f/cases/21508 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

Re: [Pharo-dev] [Ann] Commander shortcuts in Settings Browser

by Tudor Girba

Nice work! Doru > On Mar 6, 2018, at 5:05 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > With latest version of Commander and Calypso we will have all shortcuts explorable and configurable in Settings Browser: > > <ShortcutsSettingsBrowser.png> > â > Currently it uses command class name and class comment for presentation. We can improve it in future if necessary. > In addition you can add single shortcut to your own application settings. For example: > > MyApp class>>appSettingsOn: aBuilder > <systemsettings> > > ann := ClySpawnFullBrowserCommand classAnnotationAt: #browserShortcutActivation. > (ann buildSettingNodeOn: aBuilder) > label: 'My app shortcut'; > description: 'This command opens browser' > > Shortcut settings are persisted as all other settings. Only redefined shortcuts are stored into the file. > > This version also allows to add commands into the world menu and world shortcuts. Just use CmdWorldMenuContext for command annotations: > > CmdOpenFamilyBookCommand class>>worldMenuActivation > <classAnnotation> > ^CmdContextMenuCommandActivation byRootGroupItemFor: CmdWorldMenuContext > > CmdOpenFamilyBookCommand class>>globalShortcutActivation > <classAnnotation> > ^CmdShortcutCommandActivation by: $o meta, $f meta for: CmdWorldMenuContext > > (CmdOpenFamilyBookCommand is a command from Commander-Examples package). > > Nice detail: all shortcuts are updated immediately when you modify annotations either from settings or programmatically from browser. > > Now pull request for Pharo 7 is waiting integration. Soon it will be inside. > > Best regards, > Denis -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

March 6, 2018

Re: [Pharo-dev] [Vm-dev] FFI Struct Argument Pass By Value Fails on Mac 64 bit

by Todd Blanchard

Silly me. I have no idea how to update this library. I thought it would be a file. I've used Monticello years ago in Squeak - however trying to load this repository into Pharo 6.1-64 is impossible. Invariably I end up with an undefined symbol and a couple of undismissable progress dialogs. Also, its .c files that compile into a library, right? Where would such files be in this repository? I love Smalltalk. I'm really starting to hate this though. > On Mar 1, 2018, at 10:25 AM, todd blanchard <tblanchard(a)mac.com> wrote: > > I'm mac osx > > I will update the test library and ping back > >> On Mar 1, 2018, at 10:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Todd, >> >> On Thu, Mar 1, 2018 at 10:01 AM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> Hi Todd, >> >> On Sun, Nov 26, 2017 at 8:24 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> i'm getting the idea that we should probably write a test suite/library for FFI >> >> See the package FFI-Tests at http://source.squeak.org/FFI <http://source.squeak.org/FFI> and the file sqFFITestFuncs.c <http://sqffitestfuncs.c/> >> >> I suggest you extend these with an example that demonstrates your failing case. One thing to be very careful about is the platform. Are you on Mac OS X, linux or Win64? Mac OS X & linux use the SysV ABI (see e.g. https://software.intel.com/sites/default/files/article/402129/mpx-linux64-a… <https://software.intel.com/sites/default/files/article/402129/mpx-linux64-a…>) whereas Win64 uses Microsoft's own ABI (see https://msdn.microsoft.com/en-us/library/ms235286.aspx?f=255&MSPPError=-214… <https://msdn.microsoft.com/en-us/library/ms235286.aspx?f=255&MSPPError=-214…>). In particular under the Sys V ABI certain structs (structs having two 64-bit fields) will be passed in registers, if two registers are available at that point in the parameter list. The ThreadedX64SysVFFIPlugin is written to pass structs in this manner but there may be bugs in the code to identify precisely those structs that fulfill the register passing criterion. Microsoft's own ABI passes structs of size 8, 16, 32, or 64 bits and __m64 in a single register. The ThreadedX64Win64FFIPlugin is written to pass structs in this manner but again there may be bugs in the code to identify precisely those structs that fulfill the register passing criterion. >> >> >> HTH >> >>> On Nov 24, 2017, at 12:54 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> >>> >>> On 24 November 2017 at 13:16, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> >>> On 22 November 2017 at 21:59, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> >>> On 22 November 2017 at 13:38, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>> >>> I've been trying to track this down for a couple weeks now. >>> >>> I have concluded that structs passed by value to functions on the 64 bit VM are not properly populated. The struct's memory is all zero'd. >>> >>> I found this while trying to work with LibClang and found that functions that fetched code locations from code ranges always returned invalid zero'd locations. After spending some time with lldb I have traced the problem into the native code and found that the argument is not correct. >>> >>> I've carved out the wee bit of clang to reproduce this in a tiny library. >>> >>> The gist of it is below and the entire file is included. Basically the struct passed to the function clang_getRangeStart is zero'd memory regardless of the data I send from the image side. >>> >>> The build command I used on sierra is clang -shared -undefined dynamic_lookup -o microclang.dylib microclang.c >>> >>> On Ubuntu 16.04 I used... >>> $ clang -shared -fPIC -o libmicroclang.so microclang.c >>> >>> $ clang test.c -L. -l microclang >>> test.c:6:53: error: no member named 'begin_int_data' in 'CXSourceLocation' >>> if(clang_getRangeStart(clang_getArbitraryRange()).begin_int_data == 0) >>> >>> I presume you meant... >>> if(clang_getRangeStart(clang_getArbitraryRange()).int_data == 0) >>> so correcting and continuing... >>> >>> $ clang test.c -L. -l microclang >>> $ LD_LIBRARY_PATH=. ./a.out >>> That failed >>> >>> So I'm not sure how to proceed. >>> I was expecting that would work while Pharo failed. >>> >>> Now interestingly... >>> $ clang test.c microlang.c >>> $ ./a.out >>> That worked >>> >>> >>> So it seems a similar problem exists outside our FFI. >>> >>> cheers -ben >>> >>> P.S. I refactored you code to extract a header file (attached) >>> >>> The issue is still beyond my ken, but I've made some progress towards isolating/understanding the issue. >>> Attached zip exploded here for easy reference... >>> >>> >>> ___microlang.h___ >>> typedef unsigned uintptr_t; >>> >>> typedef struct { >>> const void *ptr_data[2]; >>> } CXSourceRange_; >>> >>> CXSourceRange_ clang_getArbitraryRange_(); >>> int clang_getRangeEnd_(CXSourceRange_ range); >>> >>> >>> >>> ___microclang.c___ >>> #include "microclang.h" >>> const char* libraryString = "library_pointer"; >>> >>> CXSourceRange_ clang_getArbitraryRange_() >>> { CXSourceRange_ range = {0}; >>> range.ptr_data[0] = (void*)libraryString; >>> return range; >>> } >>> >>> int clang_getRangeEnd_(CXSourceRange_ range) >>> { // Special decoding for CXSourceLocations for CXLoadedDiagnostics. >>> if ((uintptr_t)range.ptr_data[0] & 0x1) >>> { return 0; } >>> else >>> { return 1; } >>> } >>> >>> >>> >>> >>> ___test.c___ >>> #include <stdio.h> >>> #include "microclang.h" >>> const char* localString = "local_pointer"; >>> >>> void test( CXSourceRange_ range, char *note ) >>> { int result = clang_getRangeEnd_(range); >>> if(result == 0) >>> { printf("That failed (%s)\n", note); } >>> else >>> { printf("That worked (%s)\n", note); } >>> } >>> >>> int main() >>> { CXSourceRange_ range1 = clang_getArbitraryRange_(); >>> test(range1, "library string"); >>> >>> CXSourceRange_ range2 = {0}; >>> range2.ptr_data[0] = (void*)localString; >>> test(range2, "local string"); >>> } >>> >>> >>> >>> ___Makefile___ >>> default: clean static shared >>> >>> clean: >>> rm -f *so *App >>> @echo >>> >>> shared: >>> clang -g -o libmicroclang.so -shared -fPIC microclang.c >>> clang -g -o sharedApp test.c -L. -lmicroclang >>> LD_LIBRARY_PATH=. ./sharedApp >>> @echo >>> >>> static: >>> clang -g -o staticApp test.c microclang.c >>> ./staticApp >>> @echo >>> >>> >>> >>> Now running... >>> $ make > report >>> >>> gives... >>> ___report___ >>> rm -f *so *App >>> >>> clang -g -o staticApp test.c microclang.c >>> ./staticApp >>> That worked (library string) >>> That worked (local string) >>> >>> clang -g -o libmicroclang.so -shared -fPIC microclang.c >>> clang -g -o sharedApp test.c -L. -lmicroclang >>> LD_LIBRARY_PATH=. ./sharedApp >>> That failed (library string) >>> That worked (local string) >>> >>> >>> Further simplification dealing *only* with strings (see attached sharedLibString.zip) >>> (also attached is clang3.zip as a step along the way) >>> >>> ___microclang.c___ >>> typedef unsigned uintptr_t; >>> const char* myLibraryString = "library_pointer"; >>> >>> const char * lib_getLibraryString() >>> { return myLibraryString; >>> } >>> >>> int lib_testString( const char *aString ) >>> { unsigned test = (uintptr_t)aString & 0x1; >>> printf("\n test=%d, aString-->%d\n", test, (uintptr_t)aString); >>> if (test) >>> { return 0; } >>> else >>> { return 1; } >>> } >>> >>> >>> ___test.c___ >>> #include <stdio.h> >>> int lib_testString( const char *aString ); >>> const char *lib_getLibraryString(); >>> const char *localString = "local_pointer"; >>> >>> void test( int result, char *note ) >>> { if(result == 0) >>> { printf("That failed (%s)\n", note); } >>> else >>> { printf("That worked (%s)\n", note); } >>> } >>> >>> int main() >>> { const char * libraryString = lib_getLibraryString(); >>> test(lib_testString(libraryString), "library string"); >>> >>> test(lib_testString(localString), "local string"); >>> } >>> >>> >>> $ make > report >>> >>> ___report___ >>> rm -f *so *App >>> >>> clang -g -o staticApp test.c microclang.c >>> ./staticApp >>> >>> test=0, aString-->4196150 >>> That worked (library string) >>> >>> test=0, aString-->4196068 >>> That worked (local string) >>> >>> clang -g -o libmicroclang.so -shared -fPIC microclang.c >>> clang -g -o sharedApp test.c -L. -lmicroclang >>> LD_LIBRARY_PATH=. ./sharedApp >>> >>> test=1, aString-->-792512599 >>> That failed (library string) >>> >>> test=0, aString-->4196484 >>> That worked (local string) >>> >>> >>> cheers -ben >>> >>> <sharedLibString.zip><clang3.zip> >> >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >

March 6, 2018

Buffer overriuns detected by fortify in the AioPlugin (was Re: Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by Eliot Miranda

Hi, aioEnable et al should really check the fd argument against FD_SETSIZE and answer error codes that get tested in clients. See two messages below: On Tue, Mar 6, 2018 at 2:49 AM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > Hi, > > I can report the following: > > The problem with the Buffer overflow remains also with OSProcess. > Also with the normal vm (https://get.pharo.org ). > > Summary: I have buffer overflow crashes with my application on Linux. > The same code runs without problems on MacOS and on Windows. > I have the same test data/database and do exactly the same. > > The problem occurs only after calling several times OSProcess/OSSubprocess. > This is the reason why I first had a suspicion that OSSubprocess is > responsible for the crashes. > > Can anyone tell me how to proceed to find the reason for the buffer > overflow? > There is no PharoDebug.log > > Help is very appreciated! > > This is the message when terminating: > > root@Pharo_ubuntu_16:/spf/build# ./pharo Pharo-Productive-SPF.image > --no-quit > > SmalltalkImageInstanceID class>>startUp*** buffer overflow detected ***: > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated > > ======= Backtrace: ========= > > /lib/i386-linux-gnu/libc.so.6(+0x67377)[0xf75b9377] > > /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x68)[0xf7649708] > > /lib/i386-linux-gnu/libc.so.6(+0xf58f8)[0xf76478f8] > > /lib/i386-linux-gnu/libc.so.6(+0xf75fa)[0xf76495fa] > > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo(aioEnab > le+0x31)[0x80c9811] > > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x81215ee] > > [0x90010e0] > > [0x90ad2d0] > > [0x90db8b4] > > [0x90ad24a] > > [0x900be6b] > > [0x900b04d] > > [0x9007a3e] > > [0x9004247] > > [0x9004572] > > [0x9001020] > > [0xa98c524] > > [0xb1755db] > > [0x9003efc] > > [0x9001020] > > [0xdcb558c] > > [0xb0d4d95] > > [0x9000ff0] > > ======= Memory map: ======== > > 08048000-08164000 r-xp 00000000 00:1b 1183256 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo > > 08164000-08165000 r--p 0011b000 00:1b 1183256 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo > > 08165000-08170000 rw-p 0011c000 00:1b 1183256 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo > > 08170000-081a7000 rw-p 00000000 00:00 0 > > 08fdd000-08ffe000 rw-p 00000000 00:00 0 > [heap] > > 09000000-09100000 rwxp 00000000 00:00 0 > > 09100000-11200000 rw-p 00000000 00:00 0 > > f552e000-f554a000 r-xp 00000000 00:1b 8244 > /lib/i386-linux-gnu/libgcc_s.so.1 > > f554a000-f554b000 rw-p 0001b000 00:1b 8244 > /lib/i386-linux-gnu/libgcc_s.so.1 > > f554b000-f684c000 rw-p 00000000 00:00 0 > > f684c000-f684f000 r-xp 00000000 00:1b 1183242 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so > > f684f000-f6850000 r--p 00002000 00:1b 1183242 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so > > f6850000-f6851000 rw-p 00003000 00:1b 1183242 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so > > f6851000-f68b2000 r-xp 00000000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b2000-f68b3000 ---p 00061000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b3000-f68b5000 r--p 00061000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b5000-f68b9000 rw-p 00063000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b9000-f6a7b000 r-xp 00000000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a7b000-f6a7c000 ---p 001c2000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a7c000-f6a8c000 r--p 001c2000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a8c000-f6a93000 rw-p 001d2000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a93000-f6a96000 rw-p 00000000 00:00 0 > > f6a96000-f6a9b000 r-xp 00000000 00:1b 1183249 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so > > f6a9b000-f6a9c000 r--p 00004000 00:1b 1183249 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so > > f6a9c000-f6a9d000 rw-p 00005000 00:1b 1183249 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so > > f6a9d000-f6ab1000 r-xp 00000000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab1000-f6ab2000 ---p 00014000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab2000-f6ab3000 r--p 00014000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab3000-f6ab4000 rw-p 00015000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab4000-f6ab6000 rw-p 00000000 00:00 0 > > f6ab6000-f6abb000 r-xp 00000000 00:1b 7931 > /lib/i386-linux-gnu/libnss_dns-2.23.so > > f6abb000-f6abc000 r--p 00004000 00:1b 7931 > /lib/i386-linux-gnu/libnss_dns-2.23.so > > f6abc000-f6abd000 rw-p 00005000 00:1b 7931 > /lib/i386-linux-gnu/libnss_dns-2.23.so > > f6abd000-f6c05000 rw-p 00000000 00:00 0 > > f6c05000-f6c2e000 r-xp 00000000 00:1b 8373 > /lib/i386-linux-gnu/libpng12.so.0.54.0 > > f6c2e000-f6c2f000 r--p 00028000 00:1b 8373 > /lib/i386-linux-gnu/libpng12.so.0.54.0 > > f6c2f000-f6c30000 rw-p 00029000 00:1b 8373 > /lib/i386-linux-gnu/libpng12.so.0.54.0 > > f6c30000-f6c49000 r-xp 00000000 00:1b 8362 > /lib/i386-linux-gnu/libz.so.1.2.8 > > f6c49000-f6c4a000 r--p 00018000 00:1b 8362 > /lib/i386-linux-gnu/libz.so.1.2.8 > > f6c4a000-f6c4b000 rw-p 00019000 00:1b 8362 > /lib/i386-linux-gnu/libz.so.1.2.8 > > f6c4b000-f6cf6000 r-xp 00000000 00:1b 8395 > /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 > > f6cf6000-f6cfa000 r--p 000aa000 00:1b 8395 > /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 > > f6cfa000-f6cfb000 rw-p 000ae000 00:1b 8395 > /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 > > f6cfb000-f6d02000 r-xp 00000000 00:1b 1183229 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so > > f6d02000-f6d03000 r--p 00006000 00:1b 1183229 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so > > f6d03000-f6d04000 rw-p 00007000 00:1b 1183229 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so > > f6d04000-f6d0f000 r-xp 00000000 00:1b 7934 > /lib/i386-linux-gnu/libnss_files-2.23.so > > f6d0f000-f6d10000 r--p 0000a000 00:1b 7934 > /lib/i386-linux-gnu/libnss_files-2.23.so > > f6d10000-f6d11000 rw-p 0000b000 00:1b 7934 > /lib/i386-linux-gnu/libnss_files-2.23.so > > f6d11000-f6d38000 rw-p 00000000 00:00 0 > > f6d38000-f6d39000 ---p 00000000 00:00 0 > > f6d39000-f7539000 rw-p 00000000 00:00 0 > [stack:21188] > > f7539000-f753b000 r-xp 00000000 00:1b 7968 > /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so > > f753b000-f753c000 r--p 00001000 00:1b 7968 > /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so > > f753c000-f753d000 rw-p 00002000 00:1b 7968 > /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so > > f753d000-f7544000 r--s 00000000 00:1b 7977 > /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache > > f7544000-f754a000 r-xp 00000000 00:1b 1183240 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so > > f754a000-f754b000 r--p 00005000 00:1b 1183240 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so > > f754b000-f754c000 rw-p 00006000 00:1b 1183240 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so > > f754c000-f754e000 r-xp 00000000 00:1b 1183257 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so > > f754e000-f754f000 r--p 00001000 00:1b 1183257 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so > > f754f000-f7550000 rw-p 00002000 00:1b 1183257 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so > > f7550000-f7552000 rw-p 00000000 00:00 0 > > f7552000-f7702000 r-xp 00000000 00:1b 7921 > /lib/i386-linux-gnu/libc-2.23.so > > f7702000-f7704000 r--p 001af000 00:1b 7921 > /lib/i386-linux-gnu/libc-2.23.so > > f7704000-f7705000 rw-p 001b1000 00:1b 7921 > /lib/i386-linux-gnu/libc-2.23.so > > f7705000-f7708000 rw-p 00000000 00:00 0 > > f7708000-f775b000 r-xp 00000000 00:1b 7917 > /lib/i386-linux-gnu/libm-2.23.so > > f775b000-f775c000 r--p 00052000 00:1b 7917 > /lib/i386-linux-gnu/libm-2.23.so > > f775c000-f775d000 rw-p 00053000 00:1b 7917 > /lib/i386-linux-gnu/libm-2.23.so > > f775d000-f7776000 r-xp 00000000 00:1b 7920 > /lib/i386-linux-gnu/libpthread-2.23.so > > f7776000-f7777000 r--p 00018000 00:1b 7920 > /lib/i386-linux-gnu/libpthread-2.23.so > > f7777000-f7778000 rw-p 00019000 00:1b 7920 > /lib/i386-linux-gnu/libpthread-2.23.so > > f7778000-f777a000 rw-p 00000000 00:00 0 > > f777a000-f777d000 r-xp 00000000 00:1b 7923 > /lib/i386-linux-gnu/libdl-2.23.so > > f777d000-f777e000 r--p 00002000 00:1b 7923 > /lib/i386-linux-gnu/libdl-2.23.so > > f777e000-f777f000 rw-p 00003000 00:1b 7923 > /lib/i386-linux-gnu/libdl-2.23.so > > f777f000-f7780000 rw-p 00000000 00:00 0 > > f7780000-f7781000 r-xp 00000000 00:00 0 > [vdso] > > f7781000-f77a4000 r-xp 00000000 00:1b 7919 > /lib/i386-linux-gnu/ld-2.23.so > > f77a4000-f77a5000 r--p 00022000 00:1b 7919 > /lib/i386-linux-gnu/ld-2.23.so > > f77a5000-f77a6000 rw-p 00023000 00:1b 7919 > /lib/i386-linux-gnu/ld-2.23.so > > ffc55000-ffcd1000 rw-p 00000000 00:00 0 > [stack] > > ./pharo: line 11: 14639 Aborted "$DIR"/"pharo-vm/pharo" > --nodisplay "$@" > > On Tue, Mar 6, 2018 at 5:26 AM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Seems to me aioEnable somehow triggers this. > It maintains buffers of size FD_SETSIZE (1024 on Linux)*, so an fd > parameter** >= that, could probably trigger such an error. > Maybe you could put a halt in whichever method in OSSubprocess/OSProcess > calls the primitive triggered when condition occurs, to see if that is the > cause? > If so, identifying *why* you end up with fd's that high (which, afaik, > isn't > normal), will probably lead to a workaround/solution... > > Cheers, > Henry > > * > https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c > 7b37bbc12cd8730c6a15f1f057c/opensmalltalk-vm/platforms/unix/vm/aio.c > ** > https://github.com/pharo-project/pharo-vm/blob/c50dec02d2875 > de56c84d11889c78484e2d5cda8/mc/VMConstruction-Plugins- > AioPlugin.package/UnixAioPlugin.class/instance/primitiveAioEnable.st > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > _,,,^..^,,,_ best, Eliot

March 6, 2018

Re: [Pharo-dev] [ANN] 64 bits support preview

by Cyril Ferlicot D.

Le 06/03/2018 Ã 04:19, Mariano Martinez Peck a Ã©critÂ : > Hi guys, > Hi! > Thanks for Guillermo Polito we now have 64 bits support for > OSSubprocess. You can see the required changes in this PR [1]. Cool :) I made a > branch called `support64bits` so that you can help us test it even if CI > said it was good [2]. If you do test it and come back to us with the > results, please tell us which OS you used.Â > > To install from the branch: > > Metacello new > Â configuration: 'OSSubprocess'; > Â repository: 'github://marianopeck/OSSubprocess:support64bits/repository'; > version: #stable; > load. > > > Roadmap: Current release isÂ v0.2.5. So I will let that release for Pharo > <= 5.0. I will make a new release with the Pharo 64 bits and call it > v0.3. That release should be used for Pharo 6.x. Once v0.3 is out, I > will make a new release v0.4 with some changes I wanted to do since a > loooong time and its a small refactor to minimize OSSubprocess > dependency on OSProcesses primitives (at VM side). This is thanks > toÂ Holger Freyther and Alistair Grant [3]. As that requires a new VM, > then v0.4 should be used in Pharo >= 7.0. > If it brings an incompatibility with older Pharo, maybe it should be a major release instead of a minor? > Cheers,Â > > > [1]Â https://github.com/marianopeck/OSSubprocess/pull/30 > [2]Â https://travis-ci.org/guillep/OSSubprocess/builds/349280174 > [3]Â https://github.com/pharo-project/pharo-vm/pull/142 > > -- > Mariano > http://marianopeck.wordpress.com -- Cyril Ferlicot https://ferlicot.fr

March 6, 2018

Metacello locking system

by Cyril Ferlicot D.

> Cyril, > > For development I tend to use Metacello locking instead of hard-wired > dependencies in the BaselineOf and that works very well --- it > completely avoids the need to edit a baseline for development purposes > and this approach works really well for me ... perhaps we can discuss > this in more detail in a separate thread or even private email? This all > seems to be more complicated for you guys than has been my experience > and of course you guys _appear_ to be completely ignoring the Metacello > locking feature so I'm curious why ... > > Dale > Hi Dale, As asked I start a new thread. I can see some possible reasons I do not use Metacello locking feature. 1) I did not understand well enough what it was 2) We have a way to work different and mine might be incompatible with the lock feature 3) I just did not see how it could help me To know which one is the reason I'll present you a little what I understood of the lock feature and how I usually work and you'll be able to advise me. For the lock feature: If I understood correctly it is a feature allowing to lock a certain version of a project in the Metacello registry. For example if I load Seaside 3.1, lock it and then install a project having Seaside 3.2 as dependency, the lock will block the update of Seaside. Now how do I usually work: Let's take the example of MaterialDesignLite that I maintain. The master branch is a branch that should only contains stable MDL versions. Ideally I would like for each commit of this branch to be tagged with a semantic versionning tag. The development happen in the development branch and new features are merged into this branch before making it to master. In general I prefer to have stricter dependencies in master than in development. So the baseline in the development branch can be different than in master. For all my projects I try to have a Jenkins building Pharo images for at least master and development, and potentially big feature branches before they are merged. The Jenkins also test the images. Then when I need to work on something, I download the Jenkins archive of the corresponding branch, double click on the image (some setting are then loaded) and I'm ready to develop because Jenkins and my settings have done all the setup. I try to keep my Jenkins script as simple as possible for the loading. Ideally I like to have something like this: ./pharo $PROJECT_NAME.image eval --save " Metacello new baseline: #MaterialDesignLite; githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish: '$VERSION' path: 'src'; onWarningLog; load. ". With this way to work, I do not really see how locks can help me. Because I don't want to have to manage possible versions I accept from all the dependencies in **development**. I want to accept the maximum of update and when it breaks either I edit the code to work with the new version of the dependency or I fix the dependency version because it will be too much work. Just to explain why I don't want to manage by hand all the dependencies version in development: I work on a project that at one time had more than 70 dependencies (transitively). Now that you know what I understood of the lock feature and that you know my way to work: Did I miss something on the lock mechanism? Do you think it can help me during my development? If yes, how would you include it in my development workflow? Thank you for the time you spend to help us improve our way to work! -- Cyril Ferlicot https://ferlicot.fr

March 6, 2018

Re: [Pharo-dev] [Ann] Commander shortcuts in Settings Browser

by Cyril Ferlicot D.

Le 06/03/2018 Ã 17:05, Denis Kudriashov a Ã©critÂ : > Hi. > > With latest version of Commander and Calypso we will have all shortcuts > explorable and configurable in Settings Browser: > > > â > Currently it uses command class name and class comment for presentation. > We can improve it in future if necessary. > In addition you can add single shortcut to your own application > settings. For example: > > MyApp class>>appSettingsOn: aBuilder > Â Â <systemsettings> > > > Â Â ann := ClySpawnFullBrowserCommand classAnnotationAt: > #browserShortcutActivation. > > Â Â (ann buildSettingNodeOn: aBuilder) > > Â Â Â Â label: 'My app shortcut'; > > Â Â Â Â description: 'This command opens browser' > > > Shortcut settings are persisted as all other settings. Only redefined > shortcuts are stored into the file. > > This version also allows to add commands into the world menu and world > shortcuts. Just use CmdWorldMenuContext for command annotations: > > CmdOpenFamilyBookCommand class>>worldMenuActivation > Â <classAnnotation> > Â ^CmdContextMenuCommandActivation byRootGroupItemFor: > CmdWorldMenuContextÂ > > > CmdOpenFamilyBookCommand class>>globalShortcutActivation > Â <classAnnotation> > Â ^CmdShortcutCommandActivation by: $o meta, $f meta for: > CmdWorldMenuContextÂ > > (CmdOpenFamilyBookCommand is a command from Commander-Examples package). > > Nice detail: all shortcuts are updated immediately when you modify > annotations either from settings or programmatically from browser.Â > > Now pull request for Pharo 7 > <https://github.com/pharo-project/pharo/pull/1037> is waiting > integration. Soon it will be inside. > > Best regards, > Denis Hi! This is really cool :) Indeed, for the Pharo release it would be much much better to have a titles instead of method selectors to display. Also, maybe we could have a way to group shortcut settings. Because latter if Commander is more used, we should have "Editor shortcuts", "Debugger shortcuts", "Iceberg shortcuts"... Thank you for the work! -- Cyril Ferlicot https://ferlicot.fr

March 6, 2018