January 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] SmallLint
by Simon Allier Jan. 15, 2012

Jan. 15, 2012

Hi, I'm working on SmallLint. I have several ideas for improving SmallLint: The correction of some rules can be automated (eg Rule Unnecessary "= true" or Variable not reference) -> add transformation to these rules. Some rules such as Spelling rules (eg comments Method: Checks for spelling errors in method comments., 7088 problems) are not very interesting and could be removed (or treated differently?) Adding an indice of difficulty to correct the rule: - Level of automation for the correction of the rule (automatic, semi-automatic, â¦). - Scope of the rule (block, method, class â¦). Other costs could be - cost of applying (may be the rule requires to compute something else, or if a rule has 50000 hits, it generates an extra cost to analyze the results) - cost of NOT applying the rule (if it could detect a bug and we don' t apply it ...) Adding a manifest to manage/mark falses positive: - one manifest (a class) by package. - Manifest: exclusion of class/method of the package for rules or for all the rules. - Exclusion of rules for the package. One could also think on how to efficiently visualize the results of smallLint ... Simon Allier

3 4

[Pharo-project] What is the difference between ActionSequence and WeakActionSequence
by Guillermo Polito Jan. 15, 2012

Jan. 15, 2012

In 1.3 they look the same, in 1.4 ActionSequence is not there any more... Is the second one replacing the first one? are there any differences for the user? Thanks, Guille

4 7

[Pharo-project] Preparing 1.4 beta
by StÃ©phane Ducasse Jan. 15, 2012

Jan. 15, 2012

Hi since we will not have OPAL as preview in 1.4 and we do not need to change the refactoring engine code, we will unload AST and RBEngine package from the system and start to pass in 1.4 beta probably at the end of the month. One idea was that we could have decent tools to work on the core but this is not the case. We will encourage people to try their packages to 1.4 beta and rc so that we can produce 1.4. Stef

4 9

[Pharo-project] [update 1.4] #14284
by StÃ©phane Ducasse Jan. 14, 2012

Jan. 14, 2012

14284 ----- - Issue 5175: CommandLine args not working. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=5175 - Issue 5171: Remove styling from PreDebug warning message. Thanks Guillermo Polito. http://code.google.com/p/pharo/issues/detail?id=5171 - Issue 5165: Incorporate to Pharo DisplayScreen options. Thanks Esteban Lorenzano. http://code.google.com/p/pharo/issues/detail?id=5165 Thanks a lot guys for your good energy. I need it. Stef

1 0

[Pharo-project] [Interesting] Drive to remove unused code in LibreOffice
by Sven Van Caekenberghe Jan. 14, 2012

Jan. 14, 2012

http://www.i-programmer.info/news/136-open-source/3607-drive-to-remove-unus… probably a problem in every large code base

4 3

Re: [Pharo-project] Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
by Lawson English Jan. 14, 2012

Jan. 14, 2012

Sounds good. BTW, the trend of popularity continues. This latest video http://www.youtube.com/watch?v=F5GHRaIwCS4 has had 45 views since I put it up yesterday and the first video on that topic is now at 145 views (my most popular video took 2 months to get that many views). Once you get NBOpenGL and GLDisplay cross-platform, I suspect there will be a rather large number of OpenGL programmers testing how it works. Games, GUI testing, algorithmic and other technical visualization. Cobalt/Croquet integration, etc. Lots of potential here. L. On 1/14/12 7:22 AM, Igor Stasenko wrote: > On 14 January 2012 07:12, Lawson English<lenglish5(a)cox.net> wrote: >> http://www.youtube.com/watch?v=F5GHRaIwCS4 >> >> nowhere near where it could be. With NBOpenGL and GLDisplay, things would be >> much snappier and easier. Of course, at this point, we need to start >> discussing how to integrate OpenGL errors into the squeak debugging system >> so that the IDE remains stable... >> > well, one of the ideas is to use fallback display in case of openGL error(s). > And render not to GL context but to bitmap. Then you can actually use > debugger to debug GL calls step by step > without interfering with GL stack/state. > Another approach would be to create a separate GL context and use it > for debugger. But then you need to keep an eye > for switching active contexts at right moment. > >> L. >>

1 0

[Pharo-project] CommentReference removed?
by Guillermo Polito Jan. 14, 2012

Jan. 14, 2012

I am trying to load OB in Pharo 1.4, but It seems CommentReference was removed from the image... Shouldn't it go to a deprecated package? Should we reitroduce it with the proper deprecation? Guille

2 3

Re: [Pharo-project] [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
by Lawson English Jan. 14, 2012

Jan. 14, 2012

[pharo list added back in for real this time] Would it be best to have a VM primitive that actually gives this info in a cross-platform way since it is going to be more and more useful as time goes on? On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: > Am 11.01.2012 19:18, schrieb Bert Freudenberg: >> ... >> This primitive encapsulates the platform-dependent part of creating an OpenGL rendering context. OpenGL itself is platform-independent, but creating a window is not. The plugin has code for Mac, Windows, and Unix. >> >> So this creates a new borderless window that gets embedded in the "big" main window. It also creates an OpenGL context for that window and makes it current. After calling the primitive you can use any OpenGL commands to draw directly into it using the hardware renderer. I don't see a good reason why you would not want to use it. >> >> - Bert - >> > I'm currently also experimenting with this (under Linux) and it looks like this does not fully work on my system - the > OpenGL output seems to be displayed for a very short moment, and then only teh Squeak desktop is visible again. > Of course, it's nice to have the platform-dependent part within the primitive, but at least for Windows and Linux/X11 > creating an OpenGL context is not really difficult, so since we already have platform-dependent OpenGL subclasses > anyway, there is no strong reason to keep the context creation stuff in primitive code. > > Cheers, > Hans-Martin > >

3 5

Jan. 13, 2012

no time to think about it but I found that interesting. Begin forwarded message: > From: Paul Baumann <paul.baumann(a)theice.com> > Subject: [vwnc] [Tuning] Set class>>new: > Date: January 11, 2012 1:11:19 AM GMT+01:00 > To: "'VWNC'" <vwnc(a)cs.uiuc.edu> > > Inspect this code to see hashed collection instances grouped by their free space percentage: > > ^((ObjectMemory allInstancesOfAny: Set withAllSubclasses asArray) asOrderedCollection > reject: [:ea | ea size < 10 ]) > groupedBy: [:ea | ea capacity / ea size - 1.0 ] > > Hashing collections in VW need to have extra space allocated to act as search limits between logical groups. Sets performance drops there are aren't many free slots allocated. When there are only 25% free slots allocated then the collection grows. VW rounds up to a prime number for instance creation and then targets 33% rounded up to a prime for growths afterwards. A target of 33% rounded to prime skimps on memory at the expense of performance. > > As a collection grows to the minimum 25% free space goal (in #fullCheck) there is a 75% chance of crossing into the next logical bucket before finding a nil value. Crossing into the next logical bucket just once can double the number of slots searched for a miss. Four logical buckets may be traversed for each search-miss by the time the 25% minimum is reached. > > When VW skimps on allocation then it has to grow collections more frequently and has to do more comparisons for each lookup. That is a general performance problem, but there is another problem with how VW allocates memory for pre-sized collections... > > When you see collections created for an expected size like these: > > anArray := Array new: 1000. > aSet := Set new: 1000. > anOc := OrderedCollection new: 1000. > aDict := Dictionary new: 1000. > > How many items would you expect each of these collections to efficiently contain? Clearly the Array will be exactly 1000. The OrderedCollection will take up to 1000 additions before it needs to grow. Pre-sized collections are created to avoid incremental growth costs. Is it not common and natural to think that the Set and Dictionary would also be created to efficiently contain 1000 items too? Would you be surprised to learn that all subclasses of Set in VW (and likely only VW) are inefficient with this kind of pre-allocation when you add 1000 objects to them? > > No application code should be expected to know how Sets are implemented and to pad sizes having knowledge of VW implementation details! Look at the capacity variances that VW creates even though the Set has been created each time to anticipate 1000 additions: > > (Set withAll: (Array new: 1000)) capacity > 1511 > > (Set withAll: ((1 to: 1000) collect: [:i | Object new ])) capacity > 1511 > > (Set new: 1000) capacity > 1009 > > ((Set new: 1000) addAll: ((1 to: 1000) collect: [:i | Object new ]); yourself) capacity > 2027 > > ((Set new) addAll: ((1 to: 1000) collect: [:i | Object new ]); yourself) capacity > 1361 > > The first four should all have the same result. The last one can be different because it is not pre-sized. The third example shows that only 0.9% free space is allocated in addition to the requested size. The fourth example shows that the under-allocation caused a growth that then over-allocated to end at 102.7% free space. The costs of the third and fourth example can be seen in more detail with this test: > > | objects set timings cap0 t0 t1 | > objects := (1 to: ObjectMemory maximumIdentityHashValue) collect: [:i | Object new]. > timings := OrderedCollection new: objects size. > t0 := t1 := Time microsecondClock. > set := Set new: objects size. > cap0 := set capacity. > objects size to: 1 by: -1 do: [ :i | > set add: (objects at: i). > i \\ 1000 = 1 ifTrue: [timings add: (t1 negated + (t1 :=Time microsecondClock))]. > ]. > (Array new: 5) > at: 1 put: cap0; "Starting capacity" > at: 2 put: set capacity; "Ending capacity" > at: 3 put: (1 - (set capacity / set size) * -100.0); "Percentage of free slots" > at: 4 put: timings asArray; "Timings of each 1000" > at: 5 put: t1 - t0; "Total time" > yourself > > #(17417 34939 113.264 #(147 264 262 261 262 262 265 261 261 260 261 260 260 2474 184 184 184) 6312) "primes" > > A difference between the first and second numbers indicates growth costs were incurred while adding. The third number shows there were 1.13 free slots allocated for each logical bucket. The last number is total execution time. Notice that performance of each group improves 41% just after the collection grows. > > Load a package named ICXVwHashTuning from the Cincom Public Code Repository and try the test again. > > #(28670 28670 74.9985 #(104 182 179 179 180 263 180 183 185 184 190 189 188 188 189 254 188) 3205) "After loading ICXVwHashTuning" > > Total execution time was cut by 49% while consuming 18% less memory and ending with a (very efficient) 75% free slots. > > When application code says "Set new: 1000" then they mean that they want a Set instance that should expect to contain 1000 additions. It is the responsibility of the Set to know how much physical space should be allocated to contain 1000 items. These are simple changes that make a broad performance improvement while also having intuitive performance. Cincom should take notice of opportunities like this but at least you can improve the performance of your existing code if they don't. > > You might want to also execute "(ObjectMemory allInstancesOfAny: Set withAllSubclasses asArray) do: [:ea | ea trim ]." to optimize free space allocation for all the hashed instances. You may notice a performance boost from doing that once after loading ICXVwHashTuning. > > Paul Baumann > > > 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

2 1

Re: [Pharo-project] [Seaside] 10 reasons why I'm using Smalltalk for airflowing
by Sven Van Caekenberghe Jan. 13, 2012

Jan. 13, 2012

On 13 Jan 2012, at 19:41, Sebastian Sastre wrote: > in this essay I've published I talk about some of the reasons why Smalltalk made sense for me: > 10 reasons why I'm using Smalltalk for airflowing [1] > > Which of course mentions Seaside and has other useful Smalltalk related links > > comments (of any kind) most welcome > > hug, > > sebastian > > o/ > > [1] http://sebastianconcept.com/brandIt/10-reasons-why-im-using-smalltalk-for-a… Excellent writeup, Sebastian, I couldn't agree more. Inspiring for the new year, thanks ! Sven PS: forwaring to the Pharo list ;-)

1 0