Squeak-dev March 2014

squeak-dev@lists.squeakfoundation.org

52 participants
139 discussions

Fwd: FogBugz (Case [Issue]13154) Pharo VM - BitBlt bug in alphaSourceBlendBits8
by Nicolai Hess 01 Apr '14

01 Apr '14

Thank you Nicolas, I verified the fix, it works. I took nicolas' change and build a windows pharo vm. changing the bit depth to 8bit littleendian (-8) works now. But there are two more issues (not related to this fix). 1. Changing Display depth to 4/8/16 shows horrible rendering artifacts (those do not occur on squeak) 2. Since refactoring some parts out of DisplayScreen into MorphicUIManager you can not change the depth from -XX to XX Display newDepth:8 has no effect if current display depth is -8. (This happens on squeak too, verified in Squeak 4.4/Squeak 4.5). BTW found this change for alphaSourceBlendBits8 its way into squeaks vm? I took the lates 4.5 allinone and the bug is still there. regards Nicolai ---------- Forwarded message ---------- From: Pharo Issue Tracker <do-not-reply(a)pharo.fogbugz.com> Date: 2014-03-30 15:49 GMT+02:00 Subject: FogBugz (Case [Issue]13154) Pharo VM - BitBlt bug in alphaSourceBlendBits8 To: "nicolaihess(a)web.de" <nicolaihess(a)web.de> [image: avatar] *Ulysse The Galactic Monkey From Outer Space* edited *Case 13154*: BitBlt bug in alphaSourceBlendBits8 <https://pharo.fogbugz.com/default.asp?13154>: *Bug* in [image: Project:] Pharo VM: 2. External * You are subscribed to this case Issue Validation Failed: https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/14726//artifact/val… Errors: 1 | *Status* changed: Resolved (Monkey is checking) [image: changed to] Work Needed [image: Priority] *Priority*: 5 - Fix If Time [image: Status] *Status*: Work Needed [image: Assigned To] *Assigned to*: Nicolas Cellier [image: Milestone] *Milestone*: Pharo3.0 Go to Case <https://pharo.fogbugz.com/default.asp?13154> No longer need updates? Unsubscribe from this case.<https://pharo.fogbugz.com/default.asp?pre=preUnsubscribe&pg=pgEditBug&comma…> Don't want FogBugz notifications anymore? Update your preferences.<https://pharo.fogbugz.com/default.asp?pg=pgPrefs> [image: FogBugz] A FogBugz case was edited by Ulysse The Galactic Monkey >From Outer Space. Case ID: 13154 Title: BitBlt bug in alphaSourceBlendBits8 Status: Work Needed Category: Bug Project: Pharo VM Area: 2. External Priority: 5 - Fix If Time Milestone: Pharo3.0: 30/03/2014 (Today) Assigned To: Nicolas Cellier URL: https://pharo.fogbugz.com/default.asp?13154 Changes: Status changed from 'Resolved (Monkey is checking)' to 'Work Needed'. Issue Validation Failed: https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/14726//artifact/val… Errors: 1 | You are subscribed to this case. If you do not want to receive automatic notifications in the future, unsubscribe (https://pharo.fogbugz.com/default.asp?pre=preUnsubscribe&pg=pgEditBug&comma…) from this case.

2 1

Re: [squeak-dev] The Trunk: Environments-cwp.49.mcz
by Balázs Kósi 31 Mar '14

31 Mar '14

Hi Colin, This breaks renaming of classes. Try: Object subclass: #Bar instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Foo'. Bar rename: #Baz. and then the binding for Baz will point to nil. The problem stems from the change of Environment>>hideBinding: because self undeclare: aBinding key from: bindings makes the binding #Bar => Baz to become a binding pointing to nil, and when we get back to Environment>>renameClass:from:to: it uses that same binding object and just changes the binding key to the new name, so at the end we have a binding #Baz => nil. Balazs

2 1

The Trunk: Environments-cwp.50.mcz
by commits＠source.squeak.org 31 Mar '14

31 Mar '14

Colin Putney uploaded a new version of Environments to project The Trunk: http://source.squeak.org/trunk/Environments-cwp.50.mcz ==================== Summary ==================== Name: Environments-cwp.50 Author: cwp Time: 31 March 2014, 1:26:54.758 pm UUID: c5bc1620-6918-4480-84b2-b3a2c167e534 Ancestors: Environments-cwp.49 Create a new binding when renaming classes. =============== Diff against Environments-cwp.49 =============== Item was changed: ----- Method: Environment>>renameClass:from:to: (in category 'classes and traits') ----- renameClass: aClass from: oldName to: newName "Rename the class, aClass, to have the title newName." | binding category | category := self organization categoryOfElement: oldName. self organization classify: newName under: category suppressIfDefault: true. self organization removeElement: oldName. + binding := self declarationOf: oldName. - binding := self associationAt: oldName. declarations removeKey: oldName. self binding: binding removedFrom: self. + binding := newName => aClass. - binding key: newName. declarations add: binding. self binding: binding addedTo: self. Smalltalk renamedClass: aClass from: oldName to: newName. SystemChangeNotifier uniqueInstance classRenamed: aClass from: oldName to: newName inCategory: category!

1 0

The Trunk: Tests-cwp.294.mcz
by commits＠source.squeak.org 31 Mar '14

31 Mar '14

Colin Putney uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-cwp.294.mcz ==================== Summary ==================== Name: Tests-cwp.294 Author: cwp Time: 31 March 2014, 1:24:25.145 pm UUID: eb1b694e-7203-41b8-966d-48442e16810e Ancestors: Tests-cwp.293 Add a test for class renaming. =============== Diff against Tests-cwp.293 =============== Item was changed: ----- Method: EnvironmentTest>>createClass: (in category 'running') ----- createClass: aSymbol | builder | builder := ClassBuilder new. + ^ builder - builder name: aSymbol inEnvironment: env subclassOf: Object type: #normal instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Test'. + ! - ! Item was added: + ----- Method: EnvironmentTest>>testRenameCreatesNewBinding (in category 'class tests') ----- + testRenameCreatesNewBinding + | class newBinding oldBinding | + env importSelf. + class := self createClass: #Griffle. + oldBinding := env bindingOf: #Griffle. + class rename: #Plonk. + newBinding := env bindingOf: #Plonk. + self deny: newBinding == oldBinding. + + self assert: nil identical: oldBinding value. + self assert: #Griffle equals: oldBinding key. + + self assert: #Plonk equals: newBinding key. + self assert: class identical: newBinding value. + !

1 0

Re: [Pharo-dev] threading in Pharo
by Eliot Miranda 31 Mar '14

31 Mar '14

Hi Ben, On Wed, Mar 26, 2014 at 7:04 AM, Ben Coman <btc(a)openinworld.com> wrote: > Eliot Miranda wrote: > > > > > On Tue, Mar 25, 2014 at 10:21 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Igor, >> >> >> you have a point but I disagree. The scheduler is defined in the >> implementation section of the blue book. It could be more explicit, but >> the blue book scheduler is a known and simple system. In my threading work >> I've made sure to preserve its semantics (cooperative within priorities, >> preemptive across priorities, thread switch at activation of non-primitive >> sends and backward branches). The only serious bug I know of (that >> preempting sends a process to the back of its run-queue) was addressed in >> Cog and the VW VM. We can and should write up the semantics, but they're >> not undefined, they're simple and they do work. >> > > Oops. I lie. There is a serious bug with Semaphore>>critical: and the > like. There's a suspension point after signal and before block evaluation > that can result in deadlock if a higher priority process signals the > semaphore. Since the higher priority process is running the lower priority > process never makes progress to run the ensure block or cvlear the flag or > whatever it needs to do, and hence the system deadlocks. This requires > thought ;-) So I do know of one outstanding bug. > > My grasp of concurrency controls hasn't been tested in 20 years, so > naively I would say: If a lower priority process "L" holds** a semaphore > when the higher priority process "H" signals the semaphore, temporarily > raise the priority of the "L", or temporarily lower the priority of "H". > Is there something simple that I missing? > There are a couple of obvious solutions. One is to avoid the suspension point somehow, another is adding priority inversion. Adding priority inversion to the scheduler is a significant change which would increase complexity. You yourself have glossed over detail by saying "temporarily". I've glossed over a lot with "somehow". How would these "temporarily"s and "somehow"s be implemented? Your design sketches are appreciated. cc'ing vm-dev and squeak dev lists. this is an important discussion. > cheers -ben > > > > >> Eliot (phone) >> >> On Mar 25, 2014, at 10:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> >> On 25 March 2014 17:31, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> Hi Igor, >>> >>> >>> On Tue, Mar 25, 2014 at 5:05 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> >>>> >>>> On 24 March 2014 22:54, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>> >>>>> On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel < >>>>> alexandre.bergel(a)me.com> wrote: >>>>> >>>>>> >> I am working on a memory model for expandable collection in Pharo. >>>>>> Currently, OrderedCollection, Dictionary and other expandable collections >>>>>> use a internal array to store their data. My new collection library recycle >>>>>> these array instead of letting the garbage collector dispose them. I simply >>>>>> insert the arrays in an ordered collection when an array is not necessary >>>>>> anymore. And I remove one when I need one. >>>>>> > >>>>>> > Hm, is that really going to be worth the trouble? >>>>>> >>>>>> This technique reduces the consumption of about 15% of memory. >>>>>> >>>>>> >> At the end, #add: and #remove: are performed on these polls of >>>>>> arrays. I haven't been able to spot any problem regarding concurrency and I >>>>>> made no effort in preventing them. I have a simple global collection and >>>>>> each call site of "OrderedCollection new" can pick an element of my global >>>>>> collection. >>>>>> >> >>>>>> >> I have the impression that I simply need to guard the access to >>>>>> the global poll, which is basically guarding #add: #remove: and #includes: >>>>>> > >>>>>> > One of the AtomicCollections might be the right things for you? >>>>>> >>>>>> I will have a look at it. >>>>>> >>>>>> >> What is funny, is that I did not care at all about multi-threading >>>>>> and concurrency, and I have not spotted any problem so far. >>>>>> > >>>>>> > There isn't any 'multi-threading' like in Java, you got a much more >>>>>> control version: cooperative on the same priority, preemptive between >>>>>> priorities. >>>>>> > So, I am not surprised. And well, these operations are likely not >>>>>> to be problematic when they are racy, except when the underling data >>>>>> structure could get into an inconsistent state itself. The overall >>>>>> operations (adding/removing/searing) are racy on the application level >>>>>> anyway. >>>>>> > >>>>>> > However, much more interesting would be to know what kind of >>>>>> benefit do you see for such reuse? >>>>>> > And especially, with Spur around the corner, will it still pay off >>>>>> then? Or is it an application-specific optimization? >>>>>> >>>>>> I am exploring a new design of the collection library of Pharo. Not >>>>>> all the (academic) ideas will be worth porting into the mainstream of >>>>>> Pharo. But some of them yes. >>>>>> >>>>>> Thanks for all your help guys! You're great! >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> An interesting method I stumbled upon which may help in >>>>> understanding how these things do work. >>>>> >>>>> BlockClosure>>valueUnpreemptively >>>>> "Evaluate the receiver (block), without the possibility of >>>>> preemption by higher priority processes. Use this facility VERY sparingly!" >>>>> "Think about using Block>>valueUninterruptably first, and think >>>>> about using Semaphore>>critical: before that, and think about redesigning >>>>> your application even before that! >>>>> After you've done all that thinking, go right ahead and use it..." >>>>> | activeProcess oldPriority result semaphore | >>>>> activeProcess := Processor activeProcess. >>>>> oldPriority := activeProcess priority. >>>>> activeProcess priority: Processor highestPriority. >>>>> result := self ensure: [activeProcess priority: oldPriority]. >>>>> >>>>> >>>> I would not recommend you to use this method for anything. >>>> This method heavily relies on how process scheduler works, and in >>>> case of any changes, it may break everything. >>>> For the sake of programming, one shall never assume there is a way to >>>> "stop the world while i busy doing something". >>>> >>> >>> Really? Surely any system as interactive as Smalltalk can benefit >>> from a stop-the-rest-of-the-world scheduling facility, and surely packaging >>> it as BlockClosure>>valueUnpreemptively would be a convenient way of doing >>> so. Surely the right attitude for an implementor of a threading system for >>> Smalltalk would be "Sure, I can implement that, even in a truly concurrent, >>> multi-processor environment". It may take some doing but it's an important >>> facility to have. It shouldn't be abused, but when you need it, you need >>> it. >>> >>> >> There should be hard guarantees from VM to do it. Right now there's none. >> That's my point. >> Like special primitive(s) for disabling interrupts/scheduling and >> enabling it back again. >> Let us be realistic: the above implementation is based on insider's >> knowledge how scheduling works, lacking any notion of contract between VM >> and image. >> Right now it just based on implementation detail rather than on >> guaranteed and well defined semantic. >> >> It is no doubt, sometimes you may need such hammer to stop the world. >> And it is no doubt (to me) that one should avoid using it unless it is >> impossible to do otherwise. >> >> >> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > > -- best, Eliot

2 1

What system is used for the new webiste?
by Lawson English 31 Mar '14

31 Mar '14

I saw "powered by Squeak" but not a mention of the webserver app. It doesn't look like anything based on on Pier or Seaside, so just wondering. Lawson -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

2 1

squeak.org code available at new SqueakServices repo
by Chris Cunnington 31 Mar '14

31 Mar '14

http://ss3.gemtalksystems.com/ss/SqueakServices.html I've created a repo on SS3 where the source for squeak.org can be found. SQSqueakApplication has an Altitude Installer script in the class comment. Chris

1 0

[ANN] Squeak 4.5
by Chris Muller 31 Mar '14

31 Mar '14

We should officially announce version 4.5 of Squeak. So! Let it be known! Squeak 4.5 is released! Home page is here: http://www.squeak.org 4.5 release notes are here: http://wiki.squeak.org/squeak/6193

8 15

Daily Commit Log
by commits＠source.squeak.org 31 Mar '14

31 Mar '14

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2014-March/006993.html Name: Environments-cwp.49 Ancestors: Environments-cwp.48 Make sure globals are properly destroyed along with their environment. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-March/006994.html Name: Tests-cwp.293 Ancestors: Tests-cwp.292 Make sure globals are properly destroyed along with their environment. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-March/006995.html Name: Morphic-dtl.722 Ancestors: Morphic-cmm.721 Utilities emptyScrapsBook is now ScrapBook current emptyScrapBook. Fix misspelling in references (emptyScrapBook not emptyScrapsBook). Retain deprecated Utilities emptyScrapsBook in case of references in external projects. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-March/006996.html Name: EToys-dtl.118 Ancestors: EToys-cmm.117 Utilities emptyScrapsBook is now ScrapBook current emptyScrapBook. Fix misspelling in references (emptyScrapBook not emptyScrapsBook). Retain deprecated Utilities emptyScrapsBook in case of references in external projects. =============================================

1 0

New Mantis bug "cant save morphic projects from the all in one"
by Herbert König 30 Mar '14

30 Mar '14

Hi, I just reported http://bugs.squeak.org/view.php?id=7814 "Can't save morphic projects from 4.5 to local disk only" I marked it as major because to my knowledge projects are distinguishing Squeak other Smalltalks. Oh, and the Bug got automatically assigned to Ken which might be rethought. Cheers Herbert

2 3

Jump to page: