- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

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

May 15, 2016

[pharo-project/pharo-core] 728a7d: 60003

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 728a7d49160272b052b923aa71a6dc1bb9682998 https://github.com/pharo-project/pharo-core/commit/728a7d49160272b052b923aa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-15 (Sun, 15 May 2016) Changed paths: M Polymorph-Widgets.package/ThemeIcons.class/instance/accessing/iconNamed_ifNone_.st M Polymorph-Widgets.package/ThemeIcons.class/instance/loading/loadIconsFromUrl.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60002.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60003.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60002.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60003.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60003 18129 ThemeIcons should store icons in an IdentityDictionarry https://pharo.fogbugz.com/f/cases/18129 http://files.pharo.org/image/60/60003.zip

May 15, 2016

[pharo-project/pharo-core] 0f6544: 60002

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0f65440719bf4a01991d19b392957773e4d55b5d https://github.com/pharo-project/pharo-core/commit/0f65440719bf4a01991d19b3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-15 (Sun, 15 May 2016) Changed paths: M NECompletion.package/NECContext.class/instance/private-type-guessing/guessGlobal_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60001.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60002.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60001.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60002.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60002 18148 NEC should guess global variables https://pharo.fogbugz.com/f/cases/18148 http://files.pharo.org/image/60/60002.zip

May 15, 2016

[pharo-project/pharo-core]

by GitHub

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

May 15, 2016

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

by Tudor Girba

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

Re: [Pharo-dev] problem with slots on proxies

by stepharo

what is the status of Ghost? Because we should get a good (and this implies documented) proxy model Stef Le 27/3/16 Ã 18:47, Denis Kudriashov a Ã©crit : > Hi > > 2016-03-26 21:54 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Hi, > > I am trying to play with some proxies that inherit from > ProtoObject have slots. For example, I try to do this, but I get > an error: > > ProtoObject subclass: #BBB > instanceVariableNames: 'variable' > classVariableNames: '' > package: 'BBB'. > BBB class allSlots first read: BBB new > > The problem is that the slot sends messages to its parent object, > such as: > IndexedSlot>>read: anObject > ^ anObject instVarAt: index > > This is a problem because a similar scenario happens also when you > open a debugger on a proxy that tries to communicate with a remote > image. > > I think that instead of sending messages to the receiver, we > should make the slot work with the mirror primitives. > > For example, we would rewrite the read: method like: > IndexedSlot>>read: anObject > ^ thisContext object: anObject instVarAt: index > > Do you agree? Can I open an issue for this? I think this is important. > > > Yes, please. > But does not thisContext degrades performance? > Guille extracted mirror primitives to separate class MirrorPrimitives > (project Mirror in Pharo repo). I think we should start to use it and > move away from context.

May 15, 2016