May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec: Rereading Dolphin book and MVP

by stepharo

Le 15/5/16 Ã 10:37, Denis Kudriashov a Ã©crit : > > Hi. > > I am sure I saw model inside presenter in Spec. It was one of reason > why presenter is better name. We had Model model. Now it is Presenter > model. > But if your wrote this there is no reference from presenter to model now? > I do not know. In the spec array there is from time to time a reference to model. The interpreter was checking from model (last time I read it before ben' refactoring) Now this is too early so that I'm clear :) > 15 Ð¼Ð°Ñ 2016 Ð³. 10:29 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > > >> > In MVP the presenter has direct access to the Model and (of >> course it means that the Model API is fixed) > > I did not mean that Model :) > I meant the relationship with View. > > Stef > >> >> Why would that be true? You can plug the necessary behavior of >> how the model can be accessed, so no need to fix the Model's API. >> After all the actual model will vary from user the user, so the >> API can't be fixed. >> >> On Sat, May 14, 2016 at 8:39 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi >> >> >> In MVP the presenter has direct access to the Model and (of >> course it means that the Model API is fixed) but I wonder if >> this would not >> >> help us simplify Spec. >> >> >> Model <---- presenter <----> View >> >> >> What do you think? >> >> >> Stef >> >> >> >

May 16, 2016

[pharo-project/pharo-core] 44051f: 60005

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 44051f43a13b4d888974a527366b588a377ec84a https://github.com/pharo-project/pharo-core/commit/44051f43a13b4d888974a527… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-15 (Sun, 15 May 2016) Changed paths: M Refactoring-Core.package/RBNamespace.class/instance/accessing/allClassesDo_.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/accessing-classes/allClasses.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/accessing-classes/allMetaClasses.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/accessing-classes/allNonMetaClasses.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/accessing-classes/classesDo_.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/environments/forClasses_.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/private/allClassesDo_.st A Refactoring-Environment.package/RBBrowserEnvironment.class/instance/private/systemDictionaryClassesDo_.st M Refactoring-Environment.package/RBClassEnvironment.class/instance/accessing-classes/classesDo_.st M Refactoring-Environment.package/RBPackageEnvironment.class/instance/accessing/classesDo_.st M Refactoring-Environment.package/RBVariableEnvironment.class/instance/private/flushCachesFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60004.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60005.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60004.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60005.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60005 18173 fix #allClasses for RBBrowserEnvironments https://pharo.fogbugz.com/f/cases/18173 http://files.pharo.org/image/60/60005.zip

May 15, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60005 Home: https://github.com/pharo-project/pharo-core

May 15, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60004 Home: https://github.com/pharo-project/pharo-core

May 15, 2016

[pharo-project/pharo-core] f52f6b: 60004

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f52f6b2226495c24b9c4d0e96cb55a5c7dc1d1b3 https://github.com/pharo-project/pharo-core/commit/f52f6b2226495c24b9c4d0e9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-15 (Sun, 15 May 2016) Changed paths: A Nautilus.package/ClassWidget.class/instance/private/abstractColorAdjust_.st M Nautilus.package/ClassWidget.class/instance/private/buildTabbedNameOf_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60003.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60004.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60003.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60004.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60004 17938 Show abstract classes in ClassWidget with emphasis 2 https://pharo.fogbugz.com/f/cases/17938 http://files.pharo.org/image/60/60004.zip

May 15, 2016

Re: [Pharo-dev] PhD Thesis offer

by stepharo

did you forward it to spanish speaking mailing lists? Stef Le 4/5/16 Ã 12:37, jannik laval a Ã©crit : > Dear friends, > > I am looking for a french student (or someone speaking french) who > wants to engage in a CIFRE PhD thesis (it is a thesis with a french > company). > > The subject is attached to the mail. > > Best regards, > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me > d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info

May 15, 2016

Re: [Pharo-dev] [ANN] Pharo 6.0 Development started

by stepharo

> as it is now is just not possible. It took Marcus and me two full weeks of working on boring details and now Iâm fried (and I know Marcus is too)â¦ now, we need to change the process so we can do this easier, then yes we can release more frequently Tell me I can also do something else during three months per year :) And multiply that by many and we see that once every year is too long. > >> - git support and process (nicolas passerini is working on it) the idea is to have a process (not just a command line) that helps us >> >> managing cross projects changes >> >> - bootstrap pavel, christophe and guille are working on it >> >> - Cargo package manager christophe should release a version soon >> >> - Epicea > this would means also (probably) changing from once the sources/changes formatâ¦ now changes keeps a delta too and there is an unnecessary overlap with epicea. One step at a time. We do not care if we have double for now. We should not lose Epicea. Stef > >> - cleaning tools, cleaning spec, ProtoObject, >> >> - being able to remove the old compiler and reload it >> >> - improving the coverage of the core bootstrap >> >> - removing useless stuff (newList, TextHolder...) >> >> - Probably 64 bits > not just probablyâ¦ this is a strong âmustâ :) > also we should not be too far from having it. > >> For Bloc it also depends on Brick. > yes, most probably we will include block but we would not replace morphic in Pharo 6â¦ is too much work and weâll take some more time for stabilising and moving onto it. > > other issues: > > - UFFI 2.0 (optimisations, better support for arrays, etc.) > - OSWindows will take over the world :) > > and I think this is enough for a version :) > > Esteban > >> stef >> >> >> > >

May 15, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Nicolai Hess

2016-02-08 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > I traced this back to > Object>>withArgs:executeMethod: > (primitive 188) > > in OpalCompiler>>#evaluate > > It does not happen on squeaks spur vm as far as I know (but I don't know > what is the latests squeak spur vm). > > > > > > 2016-02-08 5:17 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > >> Very interesting... >> >> I created case 17543 >> <https://pharo.fogbugz.com/f/cases/17543/VM-crash-in-Windows-when-compiling-…>, >> with Vincent's script and other quotes from this thread. I did it because >> this Windows issue is independent from Epicea (whose integration only >> exposed the Windows issue). >> >> Martin >> > I added a note to the issue report: the crash happens in the vm, in method compileCogMethod (mingw library __chkstk_ms). This method (__chkstk_ms) is called on the call to alloca() There is a check in compileCogMethod for the size of allocated: if (allocSize > MaxStackAllocSize) { And on a squeak cog spur vm, evaluating this long list of symbols does not crash. I compared the "Size of Stack reserve" value in the image header (PE-Header) of squeaks and pharos vm executable: squeak : 0x00400000 pharo : 0x00200000 Somehow, the default stack size is twice as large in squeak than in pharos vm. If I add this change to: CogWindowsConfig>>#setExtraTargetProperties: maker maker addExternalLibraries: self externalLibraries. maker set: 'EXECUTABLE_OUTPUT_PATH' toString: '${outputDir}'. maker set: 'CMAKE_EXE_LINKER_FLAGS' toString:'${CMAKE_EXE_LINKER_FLAGS} -Wl,--stack,4194304'. "<<---- NEW ! " maker puts: 'set_source_files_properties(${srcVMDir}/gcc3x-cointerp.c PROPERTIES COMPILE_FLAGS -O1)' the executeble will have the "Size of Stack reserve" value in pharo. And evaluating this long list of symbols does not crash the vm anymore. > >> On Sat, Feb 6, 2016 at 6:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Changing the scheduler didnât have any effect. However, it seems to me >>> that the size of the input matters. I can make it work in two ways: >>> 1. delete a line. If the lineâs too short it wonât work though >>> 2. delete a couple of characters from some symbols >>> >>> That would suggest that not the number of symbols / items in the array >>> is significant but the number of bytes. So maybe thereâs a problem with >>> memory allocation in the VM. I havenât been able to come up with an exact >>> number, but the VM starts crashing at around 7096 characters. Sometimes I >>> can go over 7100, other times not. Smaller numbers always work. >>> >>> HTH, >>> Max >>> >>> On 06 Feb 2016, at 07:25, Ben Coman <btc(a)openInWorld.com >>> <btc(a)openinworld.com>> wrote: >>> >>> On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com> >>> wrote: >>> >>> In fact, this integration step >>> (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z) >>> was >>> already passed by Epicea in December. That was before spur, it might be >>> related to spur. >>> >>> That time, the integration of Epicea revealed a bug in delay's >>> scheduling... >>> >>> >>> Was that these issues integrated in build 50466... >>> https://pharo.fogbugz.com/default.asp?17066 >>> https://pharo.fogbugz.com/default.asp?13756 >>> >>> which should have left the current scheduler as >>> DelayExperimentalSpinScheduler >>> but in current build 50564 "Delay delaySchedulerClass" --> >>> DelayMicrosecondScheduler >>> >>> Maybe Delay class >> initialize has been executed since >>> Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. >>> Scheduler := DelayMicrosecondScheduler new. >>> Scheduler startTimerEventLoop. >>> Smalltalk addToStartUpList: self. >>> >>> but I don't see any updates that might have invoked it. >>> Anyway, maybe changing that will help. >>> >>> cheers -ben >>> >>> >>> >>> maybe now it's revealing some bug in Windows+spur...? >>> >>> Martin >>> >>> >>> On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent >>> <vincent.blondeau(a)worldline.com> wrote: >>> >>> >>> If you remove any line, it stops crashingâ¦ >>> >>> I really donât know what is going onâ¦ >>> >>> >>> >>> Vincent >>> >>> >>> >>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >>> <pharo-dev-bounces(a)lists.pharo.org>] De la part de >>> Henrik Nergaard >>> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 14:03 >>> >>> >>> Ã : Pharo Development List >>> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >>> [ANN] >>> We are in "code freeze" for Pharo 5) >>> >>> >>> >>> Removing >>> >>> #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: >>> visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: >>> visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: >>> visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: >>> visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: >>> visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: >>> visitSend: )) >>> >>> And it stops crashing. >>> >>> >>> >>> - BTW, there is not crash.dmp, does it works with spur? >>> >>> >>> >>> https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… >>> >>> >>> >>> Best regards, >>> >>> Henrik >>> >>> >>> >>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >>> Blondeau Vincent >>> Sent: Friday, February 5, 2016 1:54 PM >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >>> [ANN] We are in "code freeze" for Pharo 5) >>> >>> >>> >>> Very strange bug indeed that happens on windows machines that crashes the >>> VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ >>> >>> Can someone have the same issue under Windows or Mac? >>> >>> >>> >>> To reproduce : Copy paste the contents of the attached file in the >>> playground and print it or do it >>> >>> It works on pre-spur vm. >>> >>> >>> >>> BTW, there is not crash.dmp, does it works with spur? >>> >>> Vincent >>> >>> >>> >>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >>> Marcus Denker >>> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 >>> Ã : Pharo Development List >>> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >>> [ANN] >>> We are in "code freeze" for Pharo 5) >>> >>> >>> >>> >>> >>> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>> >>> I will try do integrate it nowâ¦ >>> >>> >>> >>> >>> >>> >>> >>> No, it still fails. >>> >>> >>> >>> >>> >>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… >>> >>> >>> >>> The last test it executed seems to be this: >>> >>> running suite: Refactoring-Tests-Environment >>> >>> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... >>> >>> Very strange... >>> >>> Marcus >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> >>> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >>> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le >>> secret >>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >>> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >>> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne >>> pourra >>> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >>> efforts soient faits pour maintenir cette transmission exempte de tout >>> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >>> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >>> d'un >>> virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this >>> e-mail in error, please notify the sender immediately and destroy it. As >>> its >>> integrity cannot be secured on the Internet, the Worldline liability >>> cannot >>> be triggered for the message content. Although the sender endeavours to >>> maintain a computer virus-free network, the sender does not warrant that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted. >>> >>> >>> ________________________________ >>> >>> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >>> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le >>> secret >>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >>> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >>> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne >>> pourra >>> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >>> efforts soient faits pour maintenir cette transmission exempte de tout >>> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >>> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >>> d'un >>> virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this >>> e-mail in error, please notify the sender immediately and destroy it. As >>> its >>> integrity cannot be secured on the Internet, the Worldline liability >>> cannot >>> be triggered for the message content. Although the sender endeavours to >>> maintain a computer virus-free network, the sender does not warrant that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted. >>> >>> >>> >> >

May 15, 2016

Re: [Pharo-dev] About Pragma keyword vs Pragma selector

by stepharo

indeed :) Le 15/5/16 Ã 11:02, Tudor Girba a Ã©crit : > Hi, > > We can indeed deprecate keyword, but if we change selector to mean the pragma selector instead of method selector, we cannot deprecate that one. But, indeed, I do not think we have many users out there :). > > Cheers, > Doru > > >> On May 15, 2016, at 10:34 AM, stepharo <stepharo(a)free.fr> wrote: >> >> we can use deprecation and I do not think that there are that many usages out there. >> >> >> Le 14/5/16 Ã 15:53, Tudor Girba a Ã©crit : >>> Hi, >>> >>> I would agree with that. The only thing to take into account is that this can introduce incompatibilities with external libraries, but I do not think this would be much. >>> >>> Cheers, >>> Doru >>> >>> >>>> On May 14, 2016, at 3:03 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> I would rename >>>> >>>> Pragma>>keyword into Pragma>>selector >>>> >>>> Pragma>>selector into Pragma>>methodSelector >>>> so like that it is coherent with >>>> >>>> Message and method api and with Pragma>>methodClass >>>> Le 13/5/16 Ã 14:33, stepharo a Ã©crit : >>>>> Color >> gtInspectorColorIn: composite >>>>> <gtInspectorPresentationOrder: 30> >>>>> >>>>> composite morph >>>>> title: 'Color'; >>>>> display: [ BorderedMorph new color: self ] >>>>> >>>>> pragma := (Color >> #gtInspectorColorIn:) pragmas first >>>>> pragma arguments >>>>>> 30 >>>>> pragma keyword >>>>>> #gtInspectorPresentationOrder: >>>>> I wonder why pragma returns their selector using keyword and not selector? >>>>> >>>>> Especially since message API uses selector. >>>>> >>>>> >>>>> Pragma >> message >>>>> "Answer the message of the receiving pragma." >>>>> >>>>> ^ Message selector: self keyword arguments: self arguments. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "What we can governs what we wish." >>> >>> >>> >>> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > >

May 15, 2016

more robust tests

by stepharo

Hi While integrating some changes in P6.0 I got such tests failing. Only failing on mac. Could you check? Stef Regression GT.EventRecorder.Tests.Core.GTEventRecorderTest.testAddCollector3 (from GT-EventRecorder-Tests) Failing for the past 1 build (Since Unstable#7 ) Took 0.96 sec. add description Error Message Assertion failed Stacktrace GTEventRecorderTest(TestAsserter)>>assert: GTEventRecorderTest(TestAsserter)>>deny: GTEventRecorderTest>>assertReceiverSemaphore GTEventRecorderTest>>waitForDelivery GTEventRecorderTest>>testAddCollector3 GTEventRecorderTest(TestCase)>>performTest Stef

May 15, 2016