- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14409
by Marcus Denker March 24, 2012

March 24, 2012

14409 ----- Issue 5535: DropListItem class>>#example references non-existing class http://code.google.com/p/pharo/issues/detail?id=5535 Issue 5496: UIManager>>grafPort should be made abstract (#grafPort not needed) http://code.google.com/p/pharo/issues/detail?id=5496 Issue 5475: flat padded date formats (added tests) http://code.google.com/p/pharo/issues/detail?id=5475 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Seth Talk at BoS 2008 Is The Marketing Lesson Every Engineer and Specialist Must Watch
by Sebastian Sastre March 23, 2012

March 23, 2012

Hey guys, this is an oldie, but I think it's relevant to make this well known in our community: Seth Talk at BoS 2008 Is The #Marketing Lesson Every Engineer and Specialist Must Watch [1] #software #business cheers, sebastian o/ [1] http://sebastianconcept.com/brandIt/seth-talk-at-bos-2008-is-the-marketing-…

1 0

[Pharo-project] Needs help with hang images
by Denis Kudriashov March 23, 2012

March 23, 2012

Hello. I have standalone application with UI which hangs sometime (very *rarely*). This application has many threads which interacts with server. All interactions with server and UI activity logged. But at hang state there are no new log entries. There are no server interactions. It looks like all VM block image stuff. ("alt ." not work too). Logs always finished at same position. I know where I should add extra logging which give me information before hang. So I need help. What information about system can help me? What code I should use? Is somebody has same problems? Application uses old cog VM (maybe one of first distributions from Eliot) and Pharo1.1. Application uses continuations actively. I want try updated VM. What version I should use? I need most reliable cog (not latest I think). Best regards, Denis

4 5

Re: [Pharo-project] Behavior modification VM crash
by Eliot Miranda March 23, 2012

March 23, 2012

Camillo, On Fri, Mar 23, 2012 at 5:13 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-03-22, at 23:41, Eliot Miranda wrote: > > > > > > > On Thu, Mar 22, 2012 at 3:32 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > > On 2012-03-22, at 17:26, Eliot Miranda wrote: > > > > > > > > > > > On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > > > > On 2012-03-22, at 15:06, Stefan Marr wrote: > > > > > > > > > > > On 22 Mar 2012, at 14:45, Camillo Bruni wrote: > > > > > > > >> let's have some fun and do > > > >> > > > >> Object subclass: #Behavior > > > >> uses: TPureBehavior > > > >> instanceVariableNames: 'superclass methodDict format layout' > > > >> classVariableNames: 'ObsoleteSubclasses' > > > >> poolDictionaries: '' > > > >> category: 'Kernel-Classes' > > > >> > > > >> proceed over the several warnings not to change Behavior and BOOM! > :D > > > > > > > > Check classNameIndex and thisClassIndex in the VM implementation. > > > > They are typically the hardcoded indices into the expected object > layout of Class objects. > > > > > > > > And you just changed the layout -> BOOM! magic ;) > > > > > > > > I don't know how much overhead it is to examine such kind of indices > dynamically, but we do deduce indices based on inst var names to be able to > support the different object layouts. > > > > For my stuff, I do that at VM startup, which would not help you. > > > > > > They would be expensive to recompute all the time (they're used in > debug printing). But they're not expensive to compute. So they could be > recomputed easily. See below. > > > > > > > > > > David did it dynamically for the Process class and checked the > object identity of the class I think, to know when to update the index > table after a layout change. > > > > > > right. I guess I will have to move it to some further position... > > > although I have an old image with: > > > > > > Behavior subclass: #ClassDescription > > > layout: PointerLayout > > > uses: TClassAndTraitDescription > > > slots: { > > > #instanceVariables => Slot. > > > #organization => Slot. > > > #layout => Slot. > > > } > > > classSlots: {} > > > globals: '' > > > category: #'Kernel-Classes' > > > > > > > > > which works under said Cog version :/. I guess I will just have to > find some older VM which will support the changes > > > > > > I think we should make the VM work for this. classNameIndex and > thisClassIndex should only be used for debug printing, at least thats my > intent, and it would be possible to flush them and recompute them as a > side-effect of e.g. a flushCache primitive. > > > > > > Camilo, would you create a reproducible case for me, an image that > applies this change at start-up? Thanks. > > > > > > Also, can we please get into the habit of cc'ing vm-dev for issues > that touch on the VM? I ask this so that subsequent searching for VM > issues can be confined to a search of vm-dev archives. Again AdvThanksance. > > > > Submitted a bug report here: > > http://code.google.com/p/cog/issues/detail?id=76 > > > > the attached *.st files fail under Cog / StackVM. It would be indeed > nice if they would work. > > > > Which maybe it will one day if you can put in the effort to describe how > to reproduce the bug properly. There's no pointer to a suitable image. > There are no instructions beyond "use these files". How about a link to > an image, plus a small script that files in the files? Or even better how > about constructing an image that does this at startup so that the VM > maintainers only have to fire up the image instead of wasting time setting > up files? > > you know command line? > you know images? > > cool here we go.... > > > path/to/my/crashing/vm path/to/anImage.iamge > absolute/path/to/the/scripts/attached/to/the/bug/regport.st this is simply an insult on your part. You cannot even bother to specify a Pharo version. I use Squeak, and Newspeak. I don't use Pharo except for investigating VM bugs, for the benefit of the Pharo community as well as for Cog's overall quality. I give my limited time to the Pharo community in providing a significantly improved VM. Is it too much to ask that you can provide helpful bug reports that save me time? Or do you think I am your lackey to exploit and insult? > > here we go (mario) > > > -- best, Eliot

1 0

[Pharo-project] Pharo Kernel Reload Tests-Unix - Build # 34 - Still unstable!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr March 23, 2012

March 23, 2012

1 0

[Pharo-project] About 1.4 Release...
by Marcus Denker March 23, 2012

March 23, 2012

Hi, We were discussing here about the 1.4 release... and my standpoint is: "What is on the Build Server will be the Release" For 1.4, this means that this image is the release image: https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifac… possibly with more bugs fixed. the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not. Is that what we want? or will people say "without refactorings, I will not use it?" Marcus -- Marcus Denker -- http://marcusdenker.de

5 7

[Pharo-project] direct object manipulation
by Francisco Garau March 23, 2012

March 23, 2012

Hi - what packages can be used in latest Pharo to manipulate objects directly? I am thinking something like MorphicWrappers, NakedObjects or Gaucho. Cheers, Francisco

3 2

[Pharo-project] Pharo 1.4 Tests-Mac - Build # 287 - Still Unstable!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr March 23, 2012

March 23, 2012

1 0

March 23, 2012

Begin forwarded message: > From: Paul Baumann <paul.baumann(a)theice.com> > Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once (in Assets) > Date: March 23, 2012 3:12:40 PM GMT+01:00 > To: Eliot Miranda <eliot.miranda(a)gmail.com>, Reinout Heeck <vwnclist(a)soops.nl> > Cc: "vwnc(a)cs.uiuc.edu" <vwnc(a)cs.uiuc.edu> > > It sounds similar to a technique I use in GS/S code to turn ComplexBlocks into SimpleBlocks (different terminology from VW, but same idea). The "Efficient GemStone Enumeration" framework has been enhanced and simplified (http://techsupport.gemstone.com/entries/175923-efficient-gemstone-enumerati…) Sorry I haven't shared the updated version yet. One of the neat things about the new version is that it is extended to optimize blocks for enumeration. It effectively recompiles blocks to pass context into simpler blocks through extended arguments rather than having a block closure reference external context. The optimized blocks are cached for reuse. Amazing gains are achieved in GS by using SimpleBlocks instead of ComplexBlocks. The framework I mentioned makes it possible to write application code to use simple blocks but it is still up to a developer to revise code to use the simple blocks. Developers get it wrong. They sometimes go through a lot of effort to refactor code but make a mistake in the optimization that makes all that work moot. This automatic optimization eliminates those mistakes and existing code can become much faster without having to tune application code. > > Collection>>including: including1 including: including2 > collect: threeArgBlock > "Extension of GS_CollectionPerformanceBase. plb 2011.06.27" > > | results optimizedBlock | > optimizedBlock := threeArgBlock forEnumerating: self. > results := self _newCollectResultForBlock: optimizedBlock. > self > _into: results > elective: including1 > elective: including2 > elective: nil > elective: nil > keyedCollect: optimizedBlock. > self _finishedCollect: optimizedBlock > started: 0 > results: results. > ^results > > This framework is for GS/S; however, the same performance gains can be obtained in other dialects. > > Paul Baumann > > > > From: vwnc-bounces(a)cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On Behalf Of Eliot Miranda > Sent: Thursday, March 22, 2012 18:02 > To: Reinout Heeck > Cc: vwnc(a)cs.uiuc.edu > Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once (in Assets) > > > > On Thu, Mar 22, 2012 at 10:13 AM, Reinout Heeck <vwnclist(a)soops.nl> wrote: > Trying to atone for that foot in my mouth, I concocted a sketch for fixing #once. > > Clever! And that suggests a simple implementation for Squeak. Methods can maintain a map in a their properties/pragmas/method tags to map closure initial pc to cached value. Thanks!! > > Please find attached a workspace snippet that will alter the system without immediately crashing it. > When evaluating the script it will complain about undeclared names, simply hit 'leave undeclared'. > > > This implementation delegates the caching and becoming to the CompiledBlock instances instead of the BlockClosure instances that the original used. It should now work for both clean and copying blocks. > The simple test Steven Kelly supplied below should now yield true in both cases. > > This code has hardly been tested, its just a sketch and needs some cleanup (and it is developed on 771 FTW). > > In both the original and new versions I miss the flushing of the VM (JIT) caches, > could someone here with knowledge about the JIT review this apparent omission? > > > > On 3/21/2012 1:32 PM, Steven Kelly wrote: > Object class>>onceClean > "self onceClean == self onceClean" "true" > ^[Object new] once > > Object class>>onceUnclean > "self onceUnclean == self onceUnclean" "false" > ^[self new] once > > Enjoy, Reinout > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > -- > best, > Eliot > > > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

1 0

[Pharo-project] Pharo 1.4 Tests-Unix - Build # 302 - Still Unstable!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr March 23, 2012

March 23, 2012

1 0