- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] prepared inclusion of OSWindow

by Ronie Salgado

Hi Stef We don't need OSWindow-X11. I am keeping it for history purpose. It is also unmaintained. indicates > package: 'NBXLib-Core'; and I wonder why Oops, my mistake. A copy pasta. I am waiting for the inclusion to perform more testing and repairing the bugs present in Windows. Best regards, Ronie 2014-06-17 15:50 GMT-04:00 stepharo <stepharo(a)free.fr>: > 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] [ann] beacon - a slim announcement-based logging engine

by Tudor Girba

Hi Norbert, On Tue, Jun 17, 2014 at 5:09 PM, Norbert Hartl <norbert(a)hartl.name> wrote: ... > If you have an hammer everything looks like a nail. > > > Right. In my case it is just a gut feeling I had all the time. Might be it > turns out that announcements are not the way to go. But I want to look at > it. > Thanks. > To me it just kills my fun. > > I understand and Iâm sorry if the mail I wrote supported that. To be > really honest I had the same feeling when I talked with Sven and Doru. It > appeared to me that everyone wanted to place his own solution. But I like > to take the chance that we get something out where a lot of people are > happy with. On the other hand SystemLogger is not final. It can be improved > and we should improve it. Now it is the time to collaborate and tame our > egos. Otherwise there will be three half baked approaches, one in zinc, one > in GT* tools and one in pharo. That would be the worst outcome. In order to > prevent that I wanted to talk. Just that! > Indeed. I think nobody wants that. But the very fact that we are talking about ideas and that we all want to compare with one another will exactly lead us to one strong solution :) My plan is to: > > - look at beacon to see what Doru has in his mind. Maybe I get a good idea > from it > - then I would look at Svenâs new code to see the difference to Doruâs and > to actual see if that works for more than a framework > I think they are the same conceptually. On the one hand, Sven's code is more specific to Zinc, but the cool thing about it is that we get real use cases for typed events. > - finally I would like to look at the SystemLogger design again and > improve it where it might be improved. > - then there will be a new version of SystemLogger. Thatâs it. > > I personally donât plan to skip SystemLogger in favour of beacon or zinc > log. > Nor should you :). We should build one whatever the name is. Let's just take the time to compare the concepts and we see afterwards. beacon is a proof of concept but there are AFAIK no formatters, outputs and > so on. > I think Beacon is actually a full implementation of a logger. There are as many outputs as there are in the core of SystemLogger. As for formatters, I explicitly did not want them in the core because I think we should not favor text too prominently. I think that scrolling through a text file is not a good direction and that we should instead build logging analysis tools as I tried to explain in the blog post. The video of Sven shows how this can look in practice. So it is not even a replacement for SystemLogger. Zinc log is a log system > for a single framework called zinc. Iâm not sure it can be useful for > anything else and I donât think Sven is hitting in that direction. I want a > basic logging support that either has a central access for pain free > logging or it has multiple announcers (maybe one per module/framework) that > can be composed to a log source that can be attached to some kind of > dispatcher. I donât know. That I need to figure out > Great. Doru > > Norbert > > We all should review the other implementations and all of us should be > open minded for any reason why the own implementation is probably _not_ the > way to go. > I wish we can find an agreement about an optimal implementation we like to > promote. > > Norbert > > > It is called Beacon, it is based entirely on Announcements, it has > ~200 lines of code, it has no tags or levels, and in my opinion it is fully > functional. > > You can see a detailed description here including some informal > comparisons with SystemLogger: > http://www.humane-assessment.com/blog/beacon > > Please let me know what you think. I would be happy to join forces to > reach a mature solution that is both versatile and that can show how Pharo > is different. > > So should we see it as a competitor to SystemLogger? > (you will say of course not) but I do not understand. > > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 17, 2014

special meaning of keystroke Ctrl+D

by Nicolai Hess

Someone knows for why this is needed: KeyboardEvent>>#hasSpecialCTRLKeyValue " 4 - Character end 1 - Character home " ^ self controlKeyPressed and: [ keyValue <= 26 & (keyValue ~= 4) & (keyValue ~= 1) ] I know that the Ctrl-Key changes some keyvalues and so, the keycharacters have to be recomputed from the keyvalue(look at senders of #hasSpecialCTRLKeyValue). But why are 4 and 1 excluded? At least on windows, ctrl+d is mapped to "4" and with the above method ctrl+d is never recognized as ctrl+d but as ctrl+end.

June 17, 2014

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