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

Re: [Pharo-dev] argh, tests are failing!

by Denis Kudriashov

I will take a look into Mutex 2017-09-10 10:13 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi all, > > Since a couple of builds we have consistently failing the following tests: > > > - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - GT.EventRecorder.Tests.Core.GTEventRecorderTest. > testNotDeliveredDataShouldBeResent > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShoul > dUnblockWaitingOne > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > - ReleaseTests.Categorization.ProperMethodCategorizationTest. > testHashMethodNeedsToBeInComparingProtocol > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > > > Green builds are the only hard metric to say if the build is healthy or > not. > > - We should not integrate anything until the build is green again... > > Also, we spent with Pablo a lot of time to have a green build in all > platforms... I'd like to spend my time in other fun stuff than the CI :/ > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Sept. 11, 2017

Re: [Pharo-dev] Directory structure on files.pharo.org

by Guillermo Polito

On Mon, Sep 11, 2017 at 10:55 AM, stephan <stephan(a)stack.nl> wrote: > This looks like it is missing directories. > On the other hand, perhaps exposing the build steps as directories might > not be the best idea, as that is unlikely to remain stable. > http://files.pharo.org/image/70/ Yeh, also so far people will use mostly the latest minimal and full images. All intermediate steps are stored just because we can. But if you have some idea/proposal on how to enhance it, we could do it > > > Stephan > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 11, 2017

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

by stephan

On 10-09-17 11:23, Alistair Grant wrote: > Iceberg enableMetacelloIntegration: true. > Metacello new > repository: 'github://akgrant43/FileAttributes/src'; > baseline: 'FileAttributes'; > load. Pharo-7.0.0-alpha.build.110.sha.5827735.arch.64bit pharo-linux-x86_64threaded-201708312323-caa8241 Ubuntu 16.04LTS When loading: PrimitiveFailed: primitive #primFileMasks in FileAttributesPluginPrims failed Stephan

Sept. 11, 2017

Directory structure on files.pharo.org

by stephan

This looks like it is missing directories. On the other hand, perhaps exposing the build steps as directories might not be the best idea, as that is unlikely to remain stable. http://files.pharo.org/image/70/ Stephan

Sept. 11, 2017

Re: [Pharo-dev] Fuel Materialization Error

by Max Leske

Hi Sean, That cluster has been renamed. Of course, that change should be reflected in different version numbers. Unfortunately, the version number in 6.1 is not correct (thanks for finding that; I've logged it here: https://pharo.fogbugz.com/f/cases/20405/Fuel-Version-number-is-incorrect-fo… ). Now, even though you can load 1.9.4 into Pharo 6.1 that alone will not do you any good, as MethodContext has been renamed to Context (which is reflected in Fuel in the changed cluster name). >From the top of my head you would need to: 1. load Fuel 1.9.4 (i.e., load the configuration and the "(ConfigurationOfFuel project version; '1.9.4') load") 2. load your file with a migration in which you rename "MethodContext" to "Context" (see https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration) I fear that you may run into other problems later on, but I hope this helps at least a little. Cheers, Max On 9 September 2017 at 04:28:35, Sean P. DeNigris (sean(a)clipperadams.com) wrote: I'm trying to serialize in Pharo 4.0 and materialize in Pharo 6.1. Although both images claim Fuel 194, when materializing I'm getting: "KeyNotFound: key #FLMethodContextCluster not found in SystemDictionary". Anyone know what the problem is? Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 11, 2017

Re: [Pharo-dev] poor state of fuel

by H. Hirzel

On 9/10/17, Norbert Hartl <norbert(a)hartl.name> wrote: > Max, > > Just an update. Martin commited a new package that solves the > encoding/decoding of SmallInteger and Character. Together with the patch > from nicolas my dumps work again > > Norbert You mean you managed to export Fuel objects in Pharo 4 and import them in Pharo 6.1? --Hannes >> Am 29.08.2017 um 21:42 schrieb Max Leske <maxleske(a)gmail.com>: >> >> Thanks Tim. >> >> Norbert, I just saw that I have already created an issue for the 64-bit >> problems. I donât know whether tackling that will help you though. In any >> case, Iâll see that we try to work on those problems. >> >> I canât give you an exact timeline because I will be on holiday but I >> guess I can make an integration by around mid September. >> >> Cheers, >> Max >> >> >> >>> On 29 August 2017 at 16:09:06, Tim Mackinnon (tim(a)testit.works) wrote: >>> >>> As a small data point, a fuel file written out on AWS Lambda Linux (not >>> sure what version - I think it's an ubuntu, but they don't really say), >>> is readable on OS X 64bit . >>> >>> So it seems like you must have found something unusual. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> Hi Norbert, >>>> >>>> We still maintain Fuel. >>>> >>>> I was not aware of the problem you describe. Could you open an issue on >>>> github (https://github.com/theseion/Fuel/issues) with a detailed >>>> explanation and, if possible, steps to reproduce the problem? >>>> >>>> Cheers, >>>> Max >>>> >>>>> On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) >>>>> wrote: >>>>> >>>>> I'm migrating most of my projects to pharo 6.1 at the moment. I come >>>>> from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of >>>>> stuff that does not need to be installed and makes deployment better. >>>>> That really feels much better. >>>>> >>>>> I use jenkins and there if a test fails a fuel dump is written to disk. >>>>> The jenkins server is ubuntu linux with the vm of the opensuse build. >>>>> My laptop has Mac OS and cannot read back those fuel dumps. I use the >>>>> same image version on jenkins and my laptop. Both are 64bit. >>>>> >>>>> I asked that on discord and there was a mentioning that not only the 64 >>>>> bit fuel has problems. So I wanted to ask what is the state of fuel >>>>> right now. I consider fuel one of the core technologies in pharo and it >>>>> is sad if it just stops working. >>>>> >>>>> Any feedback is highly appreciated, >>>>> >>>>> Norbert >>>>> >

Sept. 11, 2017

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

by Alistair Grant

On Sun, Sep 10, 2017 at 08:38:56AM -0700, Eliot Miranda wrote: > Alistair, > > in both your crash dumps the crash is in malloc called from libgit right?. I'm not sure, the backtrace just shows: > > ======= Backtrace: ========= > > /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f76d34b37e5] > > /lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f76d34be13e] > > /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f76d34c0184] > > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo[0x4c24d0] > > [0x1c01318] > Can you build a debug vm and run under gdb and try and narrow down? I tried building a debug vm but it didn't build libgit2 or libssh2. I've never become familiar with the Make system and have only used gdb about 3 times in my entire life and none of those were in the last 15 years, so I was hoping to avoid this. :-) Anyway, I'll start trying to build a debug vm and see what I can find - but it will be slow (limited time as well as lack of experience). Cheers, Alistair > _,,,^..^,,,_ (phone) > > > On Sep 10, 2017, at 5:46 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Esteban, > > > > Another script which causes the crash: > > > > | location pharoRepository origin upstream | > > > > Iceberg enableMetacelloIntegration: true. > > Metacello new > > repository: 'github://akgrant43/pharo-akgosprocess/mc'; > > baseline: 'AKGOSProcess'; > > load. > > pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo-akgosprocess' ]. > > self halt. > > pharoRepository pull. > > > > > > I can step through to: > > > > IceLibgitLocalRepository>>changedFilesBetween:and: > > BlockClosure>>on:do: > > IceCommitInfo>>changedPackagesToCommitInfo: > > IceCommitInfo>>changedPackagesTo: > > IceRepository>>pullFrom: > > IceRepository>>pull > > UndefinedObject>>DoIt > > OpalCompiler>>evaluate > > > > and on the next step (somewhere inside #withRepoDo:): > > > > > > *** Error in `/home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo': malloc(): memory corruption: 0x00007f76c96b0f40 *** > > ======= Backtrace: ========= > > /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f76d34b37e5] > > /lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f76d34be13e] > > /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f76d34c0184] > > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo[0x4c24d0] > > [0x1c01318] > > ======= Memory map: ======== > > 00400000-0053b000 r-xp 00000000 00:29 370964 /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo > > 0073b000-0073c000 r--p 0013b000 00:29 370964 /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo > > 0073c000-0074d000 rw-p 0013c000 00:29 370964 /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo > > 0074d000-00816000 rw-p 00000000 00:00 0 > > 01b50000-01bf4000 rw-p 00000000 00:00 0 [heap] > > 01c00000-01d5e000 rwxp 00000000 00:00 0 > > 01d5e000-07d80000 rw-p 00000000 00:00 0 > > ...

Sept. 11, 2017

Re: [Pharo-dev] About Git support for windows

by H. Hirzel

A note: Both variants below do not look nice because of the code starting at the first column. Some of the method body code lines start in the first column: Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] vs. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ] What about adding 4 leading spaces, easy to remove when parsing. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] vs. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ] --Hannes On 9/11/17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I read all the morph class and I like the ending ] at the beginning of > the line (even if I know the rectangle concern for ifTrue beck > formatting) > Why because it identifies really well the end of a method. > > It is especially good for method finishing with conditionals. > > ] > > Esteban > > could you generate the same class with > > MethodDeclaration > [ > .... > ] > > I would like to browse it to see how the eye catch fast. > > because > > MethodDeclaration > [ > .... > ] > is not that nice > > so may be > > MethodDeclaration [ > .... > ] > > is a good compromise (because end of method is more important to spot that > beginning. > > Stef > >

Sept. 11, 2017

Re: [Pharo-dev] Can Realm (DB) and Pharo play together (or can we have a Pharo Realm Object Server to ROS) ?

by Todd Blanchard

Hey CÃ©drick, I do a lot of iOS development. I've looked at Realm. I don't trust it. I do like Sqlite. I have written the following frameworks for iOS. https://github.com/tblanchard/objectivefmdb I use it constantly on iOS development. I would like to port it to Pharo, possibly with GLORP front end. I have an equivalent library written in PHP (I like PHP for server work) that works against a PostgreSQL database. I use this a lot to field iOS apps with server back ends very quickly. I'm happy to share it all. But I think trying to get Realm, a proprietary data store to work well with Pharo something of a waste of time due to the proprietary nature of it. I am happy to help you out though - I've written a LOT of persistence active record type things and am pretty dang handy with GLORP as well. Drop me a note if you want to collaborate. -Todd Blanchard tblanchard(a)mac.com > On Sep 10, 2017, at 3:14 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Hello all, > > Iâve spent some time in the summer in what I call my quest to the ultimate and easy and fun architecture to prototype some personal administration apps and have fun :-) > Iâll share some experience and wonder if there are alternative in Pharo. > > I want app that are mobile firsts, then manageable with a computer (for more complex administrative tasks). > I want them reactive (I especially like reactive data driven application like meteor.js), ubiquitous around my devices and not always connected (offline-first - this is very important if not the first objective). > > Ok, so I was lurking around looking for server and mobile distributed databases and I finally found Realm (https://realm.io/products/realm-mobile-platform/ <https://realm.io/products/realm-mobile-platform/>) which is a cool architecture plenty of promises, well documented, lots of tutorials... The architecture is composed of 2 products: > - Realm DB [1] that runs on mobile device - multiplatform - fully open-source - performant - an object DB with some limitation though > - Realm Object Server (ROS) [2] - provide two-way data sync simple and easy - BUT proprietary even if free for developers â¦ the entry point for serious developments (in particular access programmatically to the server) is very expensive ! 1500$mo ! > > The developer edition with is free is already quite outstanding to me. Looks at this demo page on GitHub [3] ! > > Butâ¦ without any control to the ROS, I find ROS quite limited finally. I may then use the DB part, ROS free for what really need sync reactivity between devices or between group of people (like a black board), but store all less transient information to WhateverNoSQLDB probably in REST. > > Anyway I want to share that with you because it rings a smalltalk bell in my headâ¦ itâs about object data, live feeling, and I want to use Pharo on the server :) > > Maybe some people here have thought of an alternative ROS in Pharo or Gemstone ? Any ideas or remarks ? > I was aware of sebastian Flow living full-stack framework attempt but donât know more. > > TIA > CÃ©drick > > NB: Pharo looks more and more great ! Congratulations guys for you job ! I hope ESUG was nice. > Iâve just tried Telepharo on Pharo 6 (64 bit). Really great work too... It works like a charm, out of the box on low cost dedicated ubuntu servers [4] => 10â¬mo > Pharo 64 tinyBenchmarks is 2,75 times slower than on my Mac mini Core i5 2,5GHz from 2012 with SSD (I guess itâs not that bad and usable for personal applications servers). I think itâ about 3 times faster than on a raspberry Pi. > Mac mini (32 bit version): '1329870129 bytecodes/sec; 108576799 sends/secâ > Dedibox Low Cost server (64 bit version)â '595695171 bytecodes/sec; 39441333 sends/sec' > > NB2: to download/install Pharo from command line, on the web site instructions, it seems it lacks the trailing slash. I had to add it. > curl get.pharo.org/64 <http://get.pharo.org/64>/ | bash > > [1] https://realm.io/products/realm-mobile-database/ <https://realm.io/products/realm-mobile-database/> > [2] https://realm.io/products/realm-mobile-platform/ <https://realm.io/products/realm-mobile-platform/> > [3] https://github.com/realm-demos <https://github.com/realm-demos> > [4] https://www.online.net/fr/serveur-dedie/dedibox-sc <https://www.online.net/fr/serveur-dedie/dedibox-sc> > >

Sept. 11, 2017

Re: [Pharo-dev] About Git support for windows

by Stephane Ducasse

I read all the morph class and I like the ending ] at the beginning of the line (even if I know the rectangle concern for ifTrue beck formatting) Why because it identifies really well the end of a method. It is especially good for method finishing with conditionals. ] Esteban could you generate the same class with MethodDeclaration [ .... ] I would like to browse it to see how the eye catch fast. because MethodDeclaration [ .... ] is not that nice so may be MethodDeclaration [ .... ] is a good compromise (because end of method is more important to spot that beginning. Stef

Sept. 11, 2017