- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Esteban's ChangeLog week of 26 February 2018

by Ben Coman

On 5 March 2018 at 15:00, <estebanlm(a)gmail.com> wrote: > Hello! > > This is my weekly ChangeLog, from 26 February 2018 to 4 March 2018. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=26/2/2018&to=4/3/2018 > > ChangeLog > ========= > > 2 March 2018: > ------------- > > * I've been working on Iceberg UI. > I have first versions of: > > * repositories browser > * individual repository browser > * individual repository management browser > * commit window > * push window > * pull windows > > I'm not woking on fix a couple of problems on refreshing windows and > defining how the pull will work (by default, > it will trigger a merge of the changes your are pulling into your > image). > > > 1 March 2018: > ------------- > > * I made a new backport for 6.1, [case: 21344](https://pharo.fogbugz. > com/f/cases/21344) > > enjoy > > > 28 February 2018: > ----------------- > > * Well... I spent an stupid amount of time to figure out why the latest > VM for macOS was not including libgit2. > > Turns out, there was a "deploy filter" problem (two problems, in > fact), that was making that all pharo flavours > were being uploaded to the file server and with same name so in fact, > one flavour was being copied on top of the > other. And "lowcode VM", for example, does not includes libgi2. > > So, now that's fixed. You can start using latest VM again (which is > the one that is signed) ;) > Just to confirm, you mean downloads from here...? http://files.pharo.org/vm/pharo-spur64/mac http://files.pharo.org/vm/pharo-spur32/mac Should we expect to see a lowcode tagged VM there? cheers -ben

March 7, 2018

[Pharo 7.0-dev] Build #663: 21489 Cleanup TReplacementSequencedTest

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

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

March 7, 2018

Re: [Pharo-dev] PharoDays?

by Esteban Lorenzano

> On 28 Feb 2018, at 18:09, 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? yes, is ok for me :) Esteban > > Stef >

March 7, 2018

[Pharo 7.0-dev] Build #662: 21489 Cleanup TReplacementSequencedTest

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

There is a new Pharo build available! The status of the build #662 was: FAILURE. The Pull Request #1022 was integrated: "21489 Cleanup TReplacementSequencedTest" Pull request url: https://github.com/pharo-project/pharo/pull/1022 Issue Url: https://pharo.fogbugz.com/f/cases/21489 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 7, 2018

[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