November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

by Stephane Ducasse

thanks doru. On Sun, Nov 26, 2017 at 3:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes. They are supported since a long time. > > Alex just added support for bezier curves. For example: > https://twitter.com/feenkcom/status/934765444464021504 > > Doru > > > >> On Nov 26, 2017, at 1:52 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Aliaksei >> >> do we have support for lines? >> >> Stef >> >> On Sun, Nov 26, 2017 at 9:48 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> Did you guys ever make any progress on this? I am very interested and >>>> would like to participate if it becomes a team effortâ¦ >>> >>> Only recently I finally managed to get started with Bloc. But it is mostly >>> experiments. Mindmap has currently no timeline. (But I will be eventually >>> porting my OpenPonk to Bloc ... Mindmap could be a nice usecase). >>> >>> Peter >>> >>> On Sun, Nov 26, 2017 at 12:05 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >>> wrote: >>>> >>>> No, mind map was not implemented :) >>>> >>>> Cheers, >>>> Alex >>>> >>>> On 26 November 2017 at 00:01, Sean P. DeNigris <sean(a)clipperadams.com> >>>> wrote: >>>>> >>>>> Aliaksei Syrel wrote >>>>>> Yes, the idea of a simple game in Bloc progressed in a tutorial and a >>>>>> booklet. >>>>> >>>>> Thanks. I went through the tutorial and enjoyed it. My message was >>>>> specifically about a mind map implementation :) >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>>> >>>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > >

Nov. 26, 2017

Re: [Pharo-dev] Bloc Feedback

by Tudor Girba

I am not sure I understand: Do you confirm that examples work properly for you? Cheers, Doru > On Nov 26, 2017, at 5:51 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Aliaksei Syrel wrote >> No, they don't. You have a very old version of Gt-Examples :) > > I'm flummoxed. I downloaded a fresh Pharo 7 image via launcher, checked that > my local Bloc clone had the latest commits, and ran the "bleeding edge" > installation script from the README, namely: > Metacello new > baseline: 'Bloc'; > repository: 'github://pharo-graphics/Bloc/src'; > load: #core > > While I love what git (via e.g. GH) has made available especially regarding > social coding, at this point, I feel like I have no idea how to install > things. The results usually seem opaque and surprising :/ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Nov. 26, 2017

[Pharo 7.0-dev] Build #331: 20763 ExternalAddress>>finalize should be in finalization protocol

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

There is a new Pharo build available! The status of the build #331 was: SUCCESS. The Pull Request #547 was integrated: "20763 ExternalAddress>>finalize should be in finalization protocol" Pull request url: https://github.com/pharo-project/pharo/pull/547 Issue Url: https://pharo.fogbugz.com/f/cases/20763 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 26, 2017

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

by Sean P. DeNigris

Peter UhnÃ¡k wrote > Mindmap has currently no timeline. (But I will be eventually > porting my OpenPonk to Bloc ... Mindmap could be a nice usecase). I'd be happy to help. I've wanted a mind map (not only UI but with a real model behind it) in Pharo for a loooong time. Also, OpenPonk looks very impressive! I enjoyed the video on the webpage: https://www.youtube.com/watch?v=_gQgXdJyr-0 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 26, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > No, they don't. You have a very old version of Gt-Examples :) I'm flummoxed. I downloaded a fresh Pharo 7 image via launcher, checked that my local Bloc clone had the latest commits, and ran the "bleeding edge" installation script from the README, namely: Metacello new baseline: 'Bloc'; repository: 'github://pharo-graphics/Bloc/src'; load: #core While I love what git (via e.g. GH) has made available especially regarding social coding, at this point, I feel like I have no idea how to install things. The results usually seem opaque and surprising :/ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 26, 2017

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

by Todd Blanchard

i'm getting the idea that we should probably write a test suite/library for FFI > On Nov 24, 2017, at 12:54 AM, Ben Coman <btc(a)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>

Nov. 26, 2017

Re: [Pharo-dev] Is SmalltalkCI working for Pharo projects?

by Gabriel Cotelli

Fabio told me that seems to be a bug in SmalltalkCI related to code coverage. Tomorrow he will take a look. On Nov 26, 2017 11:13, "Aliaksei Syrel" <alex.syrel(a)gmail.com> wrote: Hi, We have the same problem. It infinitly loops on coverage and says "out of memory" in the end. Cheers, Alex On Nov 26, 2017 2:18 PM, "Gabriel Cotelli" <g.cotelli(a)gmail.com> wrote: I'm pretty sure are not my changes, because in one of the pull requests I just added Pharo 6.1 as a tested platform but no code was changed and I'm getting the same error on all the platforms ( https://github.com/ba-st/Buoy/ pull/18 ). Fabio: maybe something changed in SmalltalkCI triggering this error? From the logs seems that it's something related to coverage doing an infinite loop: IdentityDictionary(HashedCollection)>findElementOrNil: 0xc089d50: a(n) IdentityDictionary 0xfff87dd4 M IdentityDictionary(Dictionary)>at:ifAbsent: 0xc089d50: a(n) IdentityDictionary 0xfff87df4 M RGMethodDefinition(RGDefinition)>annotationNamed:ifAbsent: 0xc083658: a(n) RGMethodDefinition 0xfff87e14 M RGMethodDefinition(RGDefinition)>environment 0xc083658: a(n) RGMethodDefinition 0xfff87e30 M RGMethodDefinition(RGDefinition)>rootEnvironment 0xc083658: a(n) RGMethodDefinition 0xfff87e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff87e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff87e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff87e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff87ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff87ecc M ByteString(String)>asSymbol 0x9300760: a(n) ByteString 0xfff87ef0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff87f0c M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff87f28 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff87f40 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff87f58 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff87f70 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff87f88 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff87fac M ByteString(String)>asSymbol 0x9300780: a(n) ByteString 0xfff87fd0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff87fec M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff88008 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff88020 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff88038 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff88050 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff88068 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff8808c M ByteString(String)>asSymbol 0x93007a0: a(n) ByteString 0xfff880b0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff880cc M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff880e8 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff88100 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff88118 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff88130 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff88148 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff8816c M ByteString(String)>asSymbol 0x93007c0: a(n) ByteString 0xfff88190 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff881ac M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff85e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff85e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff85e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff85e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff85ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage On Nov 26, 2017 06:00, "Ben Coman" <btc(a)openinworld.com> wrote: The Raw Log of https://travis-ci.org/ba-st/Willow/jobs/307025742 says "The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over)." whereas the Raw Log from a working job https://travis-ci.org/ba-st/Wi llow/jobs/303028020 is 94kB. So you might start with some side-by-side diff tool to observe where these log files diverge. cheers -ben On 26 November 2017 at 03:40, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > All the latest builds I've tried are failing in Travis with "out of > memory" errors aparently after running the tests. It's always the same > error and for different Pharo versions (4.0 5.0 6.1 7.0 , etc) > > See for example https://travis-ci.org/ba-st/Willow/jobs/307025742 > > Anyone noticed something similar? > > Regards, > Gabriel >

Nov. 26, 2017

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

by Tudor Girba

Yes. They are supported since a long time. Alex just added support for bezier curves. For example: https://twitter.com/feenkcom/status/934765444464021504 Doru > On Nov 26, 2017, at 1:52 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Aliaksei > > do we have support for lines? > > Stef > > On Sun, Nov 26, 2017 at 9:48 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> Did you guys ever make any progress on this? I am very interested and >>> would like to participate if it becomes a team effortâ¦ >> >> Only recently I finally managed to get started with Bloc. But it is mostly >> experiments. Mindmap has currently no timeline. (But I will be eventually >> porting my OpenPonk to Bloc ... Mindmap could be a nice usecase). >> >> Peter >> >> On Sun, Nov 26, 2017 at 12:05 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >>> >>> No, mind map was not implemented :) >>> >>> Cheers, >>> Alex >>> >>> On 26 November 2017 at 00:01, Sean P. DeNigris <sean(a)clipperadams.com> >>> wrote: >>>> >>>> Aliaksei Syrel wrote >>>>> Yes, the idea of a simple game in Bloc progressed in a tutorial and a >>>>> booklet. >>>> >>>> Thanks. I went through the tutorial and enjoyed it. My message was >>>> specifically about a mind map implementation :) >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>> >> > -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Nov. 26, 2017

Re: [Pharo-dev] Is SmalltalkCI working for Pharo projects?

by Aliaksei Syrel

Hi, We have the same problem. It infinitly loops on coverage and says "out of memory" in the end. Cheers, Alex On Nov 26, 2017 2:18 PM, "Gabriel Cotelli" <g.cotelli(a)gmail.com> wrote: I'm pretty sure are not my changes, because in one of the pull requests I just added Pharo 6.1 as a tested platform but no code was changed and I'm getting the same error on all the platforms ( https://github.com/ba-st/Buoy/ pull/18 ). Fabio: maybe something changed in SmalltalkCI triggering this error? From the logs seems that it's something related to coverage doing an infinite loop: IdentityDictionary(HashedCollection)>findElementOrNil: 0xc089d50: a(n) IdentityDictionary 0xfff87dd4 M IdentityDictionary(Dictionary)>at:ifAbsent: 0xc089d50: a(n) IdentityDictionary 0xfff87df4 M RGMethodDefinition(RGDefinition)>annotationNamed:ifAbsent: 0xc083658: a(n) RGMethodDefinition 0xfff87e14 M RGMethodDefinition(RGDefinition)>environment 0xc083658: a(n) RGMethodDefinition 0xfff87e30 M RGMethodDefinition(RGDefinition)>rootEnvironment 0xc083658: a(n) RGMethodDefinition 0xfff87e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff87e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff87e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff87e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff87ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff87ecc M ByteString(String)>asSymbol 0x9300760: a(n) ByteString 0xfff87ef0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff87f0c M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff87f28 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff87f40 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff87f58 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff87f70 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff87f88 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff87fac M ByteString(String)>asSymbol 0x9300780: a(n) ByteString 0xfff87fd0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff87fec M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff88008 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff88020 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff88038 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff88050 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff88068 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff8808c M ByteString(String)>asSymbol 0x93007a0: a(n) ByteString 0xfff880b0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff880cc M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff880e8 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff88100 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff88118 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff88130 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff88148 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff8816c M ByteString(String)>asSymbol 0x93007c0: a(n) ByteString 0xfff88190 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff881ac M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff85e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff85e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff85e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff85e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff85ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage On Nov 26, 2017 06:00, "Ben Coman" <btc(a)openinworld.com> wrote: The Raw Log of https://travis-ci.org/ba-st/Willow/jobs/307025742 says "The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over)." whereas the Raw Log from a working job https://travis-ci.org/ba-st/Wi llow/jobs/303028020 is 94kB. So you might start with some side-by-side diff tool to observe where these log files diverge. cheers -ben On 26 November 2017 at 03:40, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > All the latest builds I've tried are failing in Travis with "out of > memory" errors aparently after running the tests. It's always the same > error and for different Pharo versions (4.0 5.0 6.1 7.0 , etc) > > See for example https://travis-ci.org/ba-st/Willow/jobs/307025742 > > Anyone noticed something similar? > > Regards, > Gabriel >

Nov. 26, 2017

Re: [Pharo-dev] Is SmalltalkCI working for Pharo projects?

by Gabriel Cotelli

I'm pretty sure are not my changes, because in one of the pull requests I just added Pharo 6.1 as a tested platform but no code was changed and I'm getting the same error on all the platforms ( https://github.com/ba-st/Buoy/ pull/18 ). Fabio: maybe something changed in SmalltalkCI triggering this error? From the logs seems that it's something related to coverage doing an infinite loop: IdentityDictionary(HashedCollection)>findElementOrNil: 0xc089d50: a(n) IdentityDictionary 0xfff87dd4 M IdentityDictionary(Dictionary)>at:ifAbsent: 0xc089d50: a(n) IdentityDictionary 0xfff87df4 M RGMethodDefinition(RGDefinition)>annotationNamed:ifAbsent: 0xc083658: a(n) RGMethodDefinition 0xfff87e14 M RGMethodDefinition(RGDefinition)>environment 0xc083658: a(n) RGMethodDefinition 0xfff87e30 M RGMethodDefinition(RGDefinition)>rootEnvironment 0xc083658: a(n) RGMethodDefinition 0xfff87e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff87e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff87e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff87e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff87ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff87ecc M ByteString(String)>asSymbol 0x9300760: a(n) ByteString 0xfff87ef0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff87f0c M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff87f28 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff87f40 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff87f58 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff87f70 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff87f88 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff87fac M ByteString(String)>asSymbol 0x9300780: a(n) ByteString 0xfff87fd0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff87fec M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff88008 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff88020 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff88038 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff88050 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff88068 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff8808c M ByteString(String)>asSymbol 0x93007a0: a(n) ByteString 0xfff880b0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff880cc M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff880e8 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff88100 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff88118 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff88130 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff88148 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage 0xfff8816c M ByteString(String)>asSymbol 0x93007c0: a(n) ByteString 0xfff88190 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n) SystemDictionary 0xfff881ac M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary 0xfff85e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658: a(n) RGMethodDefinition 0xfff85e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658: a(n) RGMethodDefinition 0xfff85e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658: a(n) RGMethodDefinition 0xfff85e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage 0xfff85ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage On Nov 26, 2017 06:00, "Ben Coman" <btc(a)openinworld.com> wrote: The Raw Log of https://travis-ci.org/ba-st/Willow/jobs/307025742 says "The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over)." whereas the Raw Log from a working job https://travis-ci.org/ba-st/Wi llow/jobs/303028020 is 94kB. So you might start with some side-by-side diff tool to observe where these log files diverge. cheers -ben On 26 November 2017 at 03:40, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > All the latest builds I've tried are failing in Travis with "out of > memory" errors aparently after running the tests. It's always the same > error and for different Pharo versions (4.0 5.0 6.1 7.0 , etc) > > See for example https://travis-ci.org/ba-st/Willow/jobs/307025742 > > Anyone noticed something similar? > > Regards, > Gabriel >

Nov. 26, 2017