June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ConfigurationOfSandstoneDB?

by Udo Schneider

On 17.06.14 19:17, Stephan Eggermont wrote:> The official repo is: That's the repo I'm using manually at the moment. > Last change was a year ago, so it might need some changes. Yep - I needed to fix some FileSystem calls. Also it seems the original configuration got lost over time. I think I'll post my fixes and a configuration on my SH page. Thanks, Udo

June 17, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Tudor Girba

Hi Stef, On Tue, Jun 17, 2014 at 4:37 PM, stepharo <stepharo(a)free.fr> wrote: > I do not understand why log should be announcement. > Especially since log: is in Object in SystemLogger. > The Log class is a carrier for the message object. The Log class is essentially doing the same thing Announcement does. So, we can just use an Announcement for that. This is not a limitation. I think it is quite beautiful. > But I will not talk about this topic anymore because I felt insulted. > Doru like do not expect that people wants to join effort on any project, > if the only reaction you have > when ask for help is to create a competitive solution. > I am sorry you felt insulted. It was not the intention at all. Perhaps my wording stroke the wrong chord, but as I tried to explain, the goal is not to pursue Beacon, but to explore the design space. I even documented, provided examples, wrote several comments in the code. I based the implementation on the argument of Sven that using Announcement is conceptually a great opportunity for a logging system and I showed that if we do that it can indeed lead to less than half the size of the other solution. In the process, I also showed how by using Announcements we need neither level nor tags. I think it is precisely in the spirit of Pharo to be able to do more with less concepts. I cannot help it to have a different opinion, but I really do not see what else I could do to make my point and contribute. I could have just committed in the SystemLogger, but that would have meant re-writing it which would have turned out to be the same thing. Would it have been better to not do anything? I hope not. So, please, let's start over and let's keep in mind that email is a poor carrier of intention. I am here precisely because I want to work together with you guys. Cheers, Doru > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

June 17, 2014

prepared inclusion of OSWindow

by stepharo

Hi Igor and Ronie following igor advice I'm preparing to integration OSWindow in Pharo. I copied all the packages to Pharo/OSWindow. Now to fully work I imagine that SDL2 should be linked to the VM so that it can work. I need to know which package make sense to be loaded I imagine that this is OSWindow-Core OSWindow-SDL2 https://pharo.fogbugz.com/default.asp?12743#103040 indicates package: 'NBXLib-Core'; and I wonder why Why do we need also the OSWindow-X11 if we use SDL Stef

June 17, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Eliot Miranda

On Tue, Jun 17, 2014 at 12:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Now, who is creative enough to add âdynamic arrayâ (one with curly braces) > and temporaries in a block to the original thing: > Don't forget a block array literal, a pragma, a long binary selector and thisContext. Personally I don't like "(each class name)". It implies one always has to parenthesize unary message sequences. The first isn't so good either since it isn't necessary. Why not true & (false not & nil isNil) ? exampleWithNumber: x > > | y | > true & false not & (nil isNil) ifFalse: [self halt]. > y := self size + super size. > #($a #a "a" 1 1.0) > do: [ :each | > Transcript show: (each class name); > show: ' ']. > ^x < y > > > > Uko > > On 16 Jun 2014, at 15:35, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> > wrote: > > > I got it from Stef, who always said it came originally from Ralph Johnson. > > http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard > > Googling around finds various copies of this, but no original source. > > Oscar > > On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf > > I think that it would be interesting to put the syntax on a postcard. It > can work as a proof of concept, some addition cheat-sheet for newcomers and > also as some king of souvenir. > > Uko > > On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: > > you have the flyer of Damien (no idea where it is) but no real postcard. > > Stef > > On 16/6/14 09:35, Yuriy Tymchuk wrote: > > Hi guys, > > we all are talking about the syntax fitting in a postcard, but was there > any real postcard with Pharo syntax prototype? This would be really > interesting. > > Uko > > > > > > > > > > -- best, Eliot

June 17, 2014

Re: [Pharo-dev] Survey: outdated slices

by Martin Dias

Thanks, Stephan! On Tue, Jun 17, 2014 at 7:12 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Not integrated yet, but this one was for 3.0. > > https://pharo.fogbugz.com/default.asp?13167#103360 > > Stephan > >

June 17, 2014

Re: [Pharo-dev] Spur Squeak Trunk Image Available

by Eliot Miranda

On Tue, Jun 17, 2014 at 10:29 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Philippe, > > > On Tue, Jun 17, 2014 at 1:03 AM, Philippe Marschall < > philippe.marschall(a)netcetera.ch> wrote: > >> On 13.06.14 01:41, Eliot Miranda wrote: >> >>> >>> >>> >>> >>> Hi All, >>> >>> it gives me great pleasure to let you know that a spur-format trunk >>> Squeak image is finally available at >>> http://www.mirandabanda.org/files/Cog/SpurImages/. Spur VMs are >>> available at http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. >>> >>> â¦ >>> >> >> I'm seeing a Seaside request handling benchmark going from 10k req/s to >> 11k req/s. >> Don't be too quick to dismiss this as being IO-bound (being IO-bound is >> actually quite hard on Squeak/Pharo). During the benchmark Squeak fully >> saturates one core. It is hard to tell what the limiting factor for this >> benchmark actually is. But removing one or two String allocations from the >> request handling loop usually yields about 100 to 200 additional req/s. >> > > That's good news at least. One thing you can try is the VMProfiler. It's > an interactive Morphic application so it will try and open and may crash > Load the VMProfiler and use it via > What I meant to say is that it may fail if the morph can't open. It doesn't routinely fail :-) > > VMProfiler openInstance > spyOn: [...]; > report: aStream. > > e.g. > VMProfiler openInstance > spyOn: [1 tinyBenchmarks]; > report: (Transcript cr; yourself). > Transcript flush. > > produces: > > /Users/eliot/Cog/oscogvm/build.macos32x86/squeak.cog.spur/Fast.app/Contents/MacOS/Squeak > 6/17/2014 > eden size: 2,603,344 stack pages: 160 code size: 1,048,576 > > 1 tinyBenchmarks > > gc prior. clear prior. > 6.298 seconds; sampling frequency 1473 hz > 9231 samples in the VM (9275 samples in the entire program) 99.53% of > total > > 8798 samples in generated vm code 95.31% of entire vm (94.86% of total) > 433 samples in vanilla vm code 4.69% of entire vm ( 4.67% of total) > > % of generated vm code (% of total) (samples) (cumulative) > 61.29% (58.13%) Integer>>benchFib (5392) (61.29%) > 13.47% (12.78%) Integer>>benchmark (1185) (74.76%) > 11.48% (10.89%) Object>>at:put: (1010) (86.24%) > 9.60% ( 9.11%) SmallInteger>>+ (845) (95.84%) > 3.99% ( 3.78%) Object>>at: (351) (99.83%) > 0.07% ( 0.06%) ceBaseFram...Trampoline(6) (99.90%) > 0.03% ( 0.03%) ceMethodAbort0Args (3) (99.93%) > 0.03% ( 0.03%) Sequenceabl...om:to:put: (3) (99.97%) > 0.02% ( 0.02%) Magnitude>>min: (2) (99.99%) > 0.01% ( 0.01%) ceEnterCog...ceiverReg (1) (100.0%) > > > % of vanilla vm code (% of total) (samples) (cumulative) > 32.33% ( 1.51%) primitiveStringReplace (140) (32.33%) > 24.25% ( 1.13%) copyAndForward (105) (56.58%) > 13.63% ( 0.64%) marryFrameSP (59) (70.21%) > 10.85% ( 0.51%) instantiateClassindexableSize (47) (81.06%) > 3.46% ( 0.16%) ceBaseFrameReturn (15) (84.53%) > 2.08% ( 0.10%) scavengeLoop (9) (86.61%) > 1.62% ( 0.08%) checkForEvent...ontextSwitch (7) (88.22%) > 1.39% ( 0.06%) externalEnsureIsBaseFrame (6) (89.61%) > 1.39% ( 0.06%) voidVMStateForSn...nalPrimitivesIf(6) (90.99%) > 1.15% ( 0.05%) mapInterpreterOops (5) (92.15%) > 1.15% ( 0.05%) returnToExecuti...tContextSwitch(5) (93.30%) > 1.15% ( 0.05%) scavengeReferentsOf (5) (94.46%) > 0.92% ( 0.04%) handleStackOverflow (4) (95.38%) > 0.92% ( 0.04%) signed64BitIntegerFor (4) (96.30%) > 0.46% ( 0.02%) primitiveShortAt (2) (96.77%) > 0.46% ( 0.02%) ceNonLocalReturn (2) (97.23%) > 0.23% ( 0.01%) gMoveCwR (1) (97.46%) > 0.23% ( 0.01%) genInnerPrimit...CharacterinReg (1) (97.69%) > 0.23% ( 0.01%) genPrimitiveMultiply (1) (97.92%) > 0.23% ( 0.01%) primitiveInflateDecompressBlock(1) (98.15%) > 0.23% ( 0.01%) primitiveNewWithArg (1) (98.38%) > 0.23% ( 0.01%) primitiveTestAnd...fCriticalSection(1) (98.61%) > 0.23% ( 0.01%) processWeaklings (1) (98.85%) > 0.23% ( 0.01%) scavengingGCTenuringIf (1) (99.08%) > 0.23% ( 0.01%) updateMaybeObjRefAt (1) (99.31%) > 0.23% ( 0.01%) wakeHighestPriority (1) (99.54%) > 0.23% ( 0.01%) ceCannotResume (1) (99.77%) > 0.23% ( 0.01%) ioPositionOfWindowSetxy (1) (100.0%) > > > > **Memory** > old +574,744 bytes > > **GCs** > full 0 totalling 0ms (0% elapsed time) > scavenges 330 totalling 93ms (1.477% elapsed time), avg 0.282ms > tenures 0 > root table 0 overflows > > **Compiled Code Compactions** > 0 totalling 0ms (0% elapsed time) > > **Events** > Process switches 66 (10 per second) > ioProcessEvents calls 314 (50 per second) > Interrupt checks 3462 (550 per second) > Event checks 3585 (569 per second) > Stack overflows 421897 (66989 per second) > Stack page divorces 0 (0 per second) > > > > While this profile is flat, it does show where the VM is spending its > time, and since the VM is not something with deep call chains, this view is > the most useful I have. > The VMProfiler is part of the CogTools package at > http://source.squeak.org/VMMaker. > > P.S. Extending the size of the DefaultTabsArray will result in a less > cramped report. > > HTH > Eliot > -- best, Eliot

June 17, 2014

Re: [Pharo-dev] Spur Squeak Trunk Image Available

by Eliot Miranda

Hi Philippe, On Tue, Jun 17, 2014 at 1:03 AM, Philippe Marschall < philippe.marschall(a)netcetera.ch> wrote: > On 13.06.14 01:41, Eliot Miranda wrote: > >> >> >> >> >> Hi All, >> >> it gives me great pleasure to let you know that a spur-format trunk >> Squeak image is finally available at >> http://www.mirandabanda.org/files/Cog/SpurImages/. Spur VMs are >> available at http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. >> >> â¦ >> > > I'm seeing a Seaside request handling benchmark going from 10k req/s to > 11k req/s. > Don't be too quick to dismiss this as being IO-bound (being IO-bound is > actually quite hard on Squeak/Pharo). During the benchmark Squeak fully > saturates one core. It is hard to tell what the limiting factor for this > benchmark actually is. But removing one or two String allocations from the > request handling loop usually yields about 100 to 200 additional req/s. > That's good news at least. One thing you can try is the VMProfiler. It's an interactive Morphic application so it will try and open and may crash Load the VMProfiler and use it via VMProfiler openInstance spyOn: [...]; report: aStream. e.g. VMProfiler openInstance spyOn: [1 tinyBenchmarks]; report: (Transcript cr; yourself). Transcript flush. produces: /Users/eliot/Cog/oscogvm/build.macos32x86/squeak.cog.spur/Fast.app/Contents/MacOS/Squeak 6/17/2014 eden size: 2,603,344 stack pages: 160 code size: 1,048,576 1 tinyBenchmarks gc prior. clear prior. 6.298 seconds; sampling frequency 1473 hz 9231 samples in the VM (9275 samples in the entire program) 99.53% of total 8798 samples in generated vm code 95.31% of entire vm (94.86% of total) 433 samples in vanilla vm code 4.69% of entire vm ( 4.67% of total) % of generated vm code (% of total) (samples) (cumulative) 61.29% (58.13%) Integer>>benchFib (5392) (61.29%) 13.47% (12.78%) Integer>>benchmark (1185) (74.76%) 11.48% (10.89%) Object>>at:put: (1010) (86.24%) 9.60% ( 9.11%) SmallInteger>>+ (845) (95.84%) 3.99% ( 3.78%) Object>>at: (351) (99.83%) 0.07% ( 0.06%) ceBaseFram...Trampoline(6) (99.90%) 0.03% ( 0.03%) ceMethodAbort0Args (3) (99.93%) 0.03% ( 0.03%) Sequenceabl...om:to:put: (3) (99.97%) 0.02% ( 0.02%) Magnitude>>min: (2) (99.99%) 0.01% ( 0.01%) ceEnterCog...ceiverReg (1) (100.0%) % of vanilla vm code (% of total) (samples) (cumulative) 32.33% ( 1.51%) primitiveStringReplace (140) (32.33%) 24.25% ( 1.13%) copyAndForward (105) (56.58%) 13.63% ( 0.64%) marryFrameSP (59) (70.21%) 10.85% ( 0.51%) instantiateClassindexableSize (47) (81.06%) 3.46% ( 0.16%) ceBaseFrameReturn (15) (84.53%) 2.08% ( 0.10%) scavengeLoop (9) (86.61%) 1.62% ( 0.08%) checkForEvent...ontextSwitch (7) (88.22%) 1.39% ( 0.06%) externalEnsureIsBaseFrame (6) (89.61%) 1.39% ( 0.06%) voidVMStateForSn...nalPrimitivesIf(6) (90.99%) 1.15% ( 0.05%) mapInterpreterOops (5) (92.15%) 1.15% ( 0.05%) returnToExecuti...tContextSwitch(5) (93.30%) 1.15% ( 0.05%) scavengeReferentsOf (5) (94.46%) 0.92% ( 0.04%) handleStackOverflow (4) (95.38%) 0.92% ( 0.04%) signed64BitIntegerFor (4) (96.30%) 0.46% ( 0.02%) primitiveShortAt (2) (96.77%) 0.46% ( 0.02%) ceNonLocalReturn (2) (97.23%) 0.23% ( 0.01%) gMoveCwR (1) (97.46%) 0.23% ( 0.01%) genInnerPrimit...CharacterinReg (1) (97.69%) 0.23% ( 0.01%) genPrimitiveMultiply (1) (97.92%) 0.23% ( 0.01%) primitiveInflateDecompressBlock(1) (98.15%) 0.23% ( 0.01%) primitiveNewWithArg (1) (98.38%) 0.23% ( 0.01%) primitiveTestAnd...fCriticalSection(1) (98.61%) 0.23% ( 0.01%) processWeaklings (1) (98.85%) 0.23% ( 0.01%) scavengingGCTenuringIf (1) (99.08%) 0.23% ( 0.01%) updateMaybeObjRefAt (1) (99.31%) 0.23% ( 0.01%) wakeHighestPriority (1) (99.54%) 0.23% ( 0.01%) ceCannotResume (1) (99.77%) 0.23% ( 0.01%) ioPositionOfWindowSetxy (1) (100.0%) **Memory** old +574,744 bytes **GCs** full 0 totalling 0ms (0% elapsed time) scavenges 330 totalling 93ms (1.477% elapsed time), avg 0.282ms tenures 0 root table 0 overflows **Compiled Code Compactions** 0 totalling 0ms (0% elapsed time) **Events** Process switches 66 (10 per second) ioProcessEvents calls 314 (50 per second) Interrupt checks 3462 (550 per second) Event checks 3585 (569 per second) Stack overflows 421897 (66989 per second) Stack page divorces 0 (0 per second) While this profile is flat, it does show where the VM is spending its time, and since the VM is not something with deep call chains, this view is the most useful I have. The VMProfiler is part of the CogTools package at http://source.squeak.org/VMMaker. P.S. Extending the size of the DefaultTabsArray will result in a less cramped report. HTH Eliot

June 17, 2014

Re: [Pharo-dev] ConfigurationOfSandstoneDB?

by Stephan Eggermont

The official repo is: MCHttpRepository location: 'http://smalltalkhub.com/mc/gnaritas/SandstoneDb/main' user: '' password: '' Last change was a year ago, so it might need some changes. Stephan

June 17, 2014

Re: [Pharo-dev] Survey: outdated slices

by Stephan Eggermont

Not integrated yet, but this one was for 3.0. https://pharo.fogbugz.com/default.asp?13167#103360 Stephan

June 17, 2014

Re: [Pharo-dev] Survey: outdated slices

by Martin Dias

On Tue, Jun 17, 2014 at 3:39 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hello dear Pharo community, > > I'm looking for fogbugz issues where a slice that was ready to be > integrated became outdated because of other issues that were > integrated before. > > In other words: the author of a slice writes it in Pharo-30XXX. Then, > a responsible of integration wants to merge it in a Pharo-30YYY (where > YYY > XXX), and the slice is rejected because it is old. > > Note: the reason of rejection can be a merge conflict, but I'm > particularly interested > in more subtle cases, where the reason was not that clear. > > Regards, > MartÃn > Clara found a possible sample: https://code.google.com/p/pharo/issues/detail?id=6621 The integration was delayed because slice was written to fix an old version of Nautilus. Thanks Clara

June 17, 2014