- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bug : [3556] Find and replace dialog behavior

by btc＠openinworld.com

Oct. 13, 2013

bug: [4993] Typing cmd+L cancel all typing and we can't undo it [Terminated]

by kilon

This is my first pharo bug fix so be gentle :D https://pharo.fogbugz.com/f/cases/4993/Typing-cmd-L-cancel-all-typing-and-w… <https://pharo.fogbugz.com/f/cases/4993/Typing-cmd-L-cancel-all-typing-and-w…> As I explain in the link and in my commit log , I have added a confirm dialog so the user in case he accidentally pressed CMD+L will click no and his changes will not be lost. I have verified the bug fix with the latest pharo build. -- View this message in context: http://forum.world.st/bug-4993-Typing-cmd-L-cancel-all-typing-and-we-can-t-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 13, 2013

Re: [Pharo-dev] Bug : [3556] Find and replace dialog behavior

by kilon

forgot to add the link to it https://pharo.fogbugz.com/f/cases/3536/Find-and-replace-dialog-behavior <https://pharo.fogbugz.com/f/cases/3536/Find-and-replace-dialog-behavior> kilon wrote > I cannot reproduce this bug. I cant find a "find and replace popup". Is > this bug still relevant ? -- View this message in context: http://forum.world.st/Bug-3556-Find-and-replace-dialog-behavior-tp4714147p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 13, 2013

Bug : [3556] Find and replace dialog behavior

by kilon

I cannot reproduce this bug. I cant find a "find and replace popup". Is this bug still relevant ? -- View this message in context: http://forum.world.st/Bug-3556-Find-and-replace-dialog-behavior-tp4714147.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 13, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30477 Home: https://github.com/pharo-project/pharo-core

Oct. 13, 2013

[pharo-project/pharo-core] ae28cd: 30477

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: ae28cda926da2447376715b7224d182d803a153d https://github.com/pharo-project/pharo-core/commit/ae28cda926da2447376715b7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-13 (Sun, 13 Oct 2013) Changed paths: M Announcements-Core.package/LegacyWeakSubscription.class/instance/finalization/unregister.st A Deprecated30.package/extension/SystemNavigation/instance/browseAllCallsOn_.st M MonticelloGUI.package/MCCodeTool.class/instance/menus/browseSendersOfMessages.st M Morphic-Base-Kernel.package/HandMorph.class/instance/balloon help/balloonHelp_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeListManager.class/instance/selection change/setSelectedMorph_.st A Morphic-Base-ProgressBar.package/SystemProgressMorph.class/class/cleanup/cleanUp.st M Morphic-Base-Worlds.package/PasteUpMorph.class/instance/drawing/drawBackgroundSketchOn_.st M Morphic-Base-Worlds.package/WorldMorph.class/instance/geometry/position_.st M NautilusCommon.package/extension/SystemNavigation/instance/confirmRemovalOfSelectors_on_.st M Polymorph-Tools-Diff.package/PSMCPatchMorph.class/instance/as yet unclassified/browseSenders.st M Polymorph-Widgets.package/TransformWithLayoutMorph.class/instance/layout/doLayoutIn_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script132.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30477.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Debugger.package/SpecDebuggerStack.class/instance/actions browsing/browseSendersOfMessages.st M Text-Edition.package/SmalltalkEditor.class/instance/menu messages/referencesTo_.st M Text-Edition.package/SmalltalkEditor.class/instance/menu messages/sendersOf_.st M Tools-Base.package/AbstractTool.class/instance/method/browseSendersOfMessagesFrom_.st M Tools-Base.package/AbstractTool.class/instance/method/removeMethod_inClass_.st M Tools-Base.package/AbstractTool.class/instance/method/removeMethods_inClass_.st M Tools-Base.package/AbstractTool.class/instance/method/selectThenBrowseSendersOfMessagesFrom_.st M Tools-Base.package/CodeHolder.class/instance/commands/browseSenders.st M Tools-Base.package/CodeHolder.class/instance/message list menu/messageListKey_from_.st M Tools-Browser.package/Browser.class/instance/message functions/removeMessage.st R Tools-Browser.package/extension/SystemNavigation/instance/browseAllCallsOn_.st A Tools-Browser.package/extension/SystemNavigation/instance/browseAllReferencesTo_.st M Tools-Browser.package/extension/SystemNavigation/instance/browseClassVarRefs_.st M Tools-File Contents Browser.package/FileContentsBrowser.class/instance/other/browseSenders.st M Tools-Finder.package/FinderMethodNode.class/instance/private/browseSenders.st M Tools-Inspector.package/DictionaryInspector.class/instance/menu/selectionReferences.st M Tools-Inspector.package/DictionaryInspector.class/instance/menu/sendersOfSelectedKey.st M Tools.package/extension/StringHolder/instance/browseSendersOfMessages.st M Tools.package/extension/StringHolder/instance/messageListKey_from_.st M Traits-Kernel-Traits.package/TClass.class/instance/compiling/innerBindingOf_.st M Traits-Kernel-Traits.package/TClassDescription.class/instance/organization/organization.st Log Message: ----------- 30477 11856 Some trivial critic changes related to ifNotNil: https://pharo.fogbugz.com/f/cases/11856 11861 Deprecated #browseAllCallsOn:, use #browseAllSendersOf: https://pharo.fogbugz.com/f/cases/11861 11857 add #cleanUp to SystemProgressMorph to reset singleton https://pharo.fogbugz.com/f/cases/11857 http://files.pharo.org/image/30/30477.zip

Oct. 13, 2013

[OT] Alan Kay last month.

by phil＠highoctane.be

http://www.heidelberg-laureate-forum.org/blog/video/lecture-friday-septembe… Phil

Oct. 13, 2013

Re: [Pharo-dev] [squeak-dev] Re: Small text composition bench

by J. Vuletich (mail lists)

Thanks Nicolas. This thread has been enlightening! I did some changes recently, mostly inspired in yours, that improve perfomance and simplify code. You can download a fully updated Cuis from https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev . It should be a bit faster. Thanks, Juan Vuletich Quoting Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I also tried composition in Cuis4.2 which is interesting because it uses the primitive 103, but is around 111ms for other reasons > > | text | > text := Compiler evaluate: (FileStream fileNamed: 'text_cuis.st[1]') contentsOfEntireFile. > MessageTally spyOn: [[100 timesRepeat: [(TextComposer new) > composeLinesFrom: 1 > to: text size > delta: 0 > into: OrderedCollection new > priorLines: OrderedCollection new > atY: 0 > text: text > extentForComposing: ( 569@9999999)]] timeToRun ]. > > 2013/10/11 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > > > > It's COG that's impressive in this case (well, as long as Spur is not ready). > > Indeed, the latest squeak still spends 713ms with a 4.10.10 interpreter VM, so primitive 103 makes a difference... > > On the Pi, it still makes sense to try and restore primitive 103 - for the simple case of StrikeFont and ByteString... > > > > 2013/10/11 David T. Lewis <lewis(a)mail.msen.com> > > > > > On Thu, Oct 10, 2013 at 05:02:56PM -0700, tim Rowledge wrote: > > > > It looks like we can feel good about the last week or so's work. Thanks for joining in and doing such good work. > > > > > > > > > > Really impressive! > > > > > > Dave Cheers, Juan Vuletich Links: ------ [1] http://text_cuis.st

Oct. 13, 2013

Re: [Pharo-dev] Start with a trivial improvement!

by Sven Van Caekenberghe

Just to add a little element: I do not know of any programming system (language, libraries, IDE) where it is possible for normal users to contribute changes like in Pharo. In most well known languages it takes years and committee decisions to make any change. In many open source projects you have to be part of an inner circle to get anything accepted. Sven On 12 Oct 2013, at 10:15, kilon <thekilon(a)yahoo.co.uk> wrote: > StÃ©phane Ducasse wrote >> On Oct 10, 2013, at 2:22 PM, kilon < > >> thekilon@.co > >> > wrote: >> >> but we are not talk ing about theory. if nobody take care about little >> glitches them you will >> have a house full of little borken glasses and dirt everywhere. And I do >> not work to live there. >> My house is cosy warm and really cool and everyday I clean it. I fix a >> door handle as soon >> as I see it having a problem not waiting that the door falls on the floor. > > You make a valid point here, I see now my post again and I dont like the way > I phrased it. What I meant to say is that if the integration process is too > slow , then people will more likely choose to create their own solutions > than bug fix the old ones, because it would be easier for them to maintain > those solutions than wait for the integration process. > > And I was wondering if that's true and how it could be avoided . I did not > mean to imply that this is a good thing, of course its not a good thing and > of course we all must help to make pharo more stable and faster. > > > Marcus Denker-4 wrote >> On Oct 12, 2013, at 6:33 AM, kilon < > >> thekilon@.co > >> > wrote: >> >> There is right now no problem to review and integrate more simple changesâ¦ >> it's the complex stuff that sometimes takes a while. >> >> For simple things we are at <24 hours. >> >> The other thing: if there are multiple people submitting simple fixes, >> these >> will very quickly start to *review* simple fixes, too. One just needs to >> start. >> >> Marcus >> >> signature.asc (210 bytes) >> <http://forum.world.st/attachment/4713991/0/signature.asc> > > I am happy you prove me wrong. 24 hours sounds very fast to me, I did not > realize that integration was so fast. I have to say that was the one thing > that was holding me back, I just did not want to invest an effort to see my > bug fix die in oblivion. > > And yes I agree , this will make it more inviting for the people to bug fix. > I will try to have a go in a couple of "easy" bug fixes. Lets put your > theory into practice , shall we ? > > > > -- > View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4714014.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 12, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Igor Stasenko

On 12 October 2013 11:08, Norbert Hartl <norbert(a)hartl.name> wrote: > So, finally it turned out that the culprit is in my own code. I was > logging exception objects that have a signaler context pointing to the > socket. This way every connection timeout I added the exception to a > collection preventing unregistering of external resources. > > Congratulations finding the bug! :) > Norbert > > Am 11.10.2013 um 15:02 schrieb Norbert Hartl <norbert(a)hartl.name>: > > > > > > > Am 11.10.2013 um 10:53 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> > >> On 11 Oct 2013, at 10:24, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >>> I can report that the behavior is different now. There were two new vm > releases this week in ppa. The first one didn't work but the second changed > something. My application was never running that long. It is more than a > day now having an actual external objects table size of 623 which wasn't > ever reached before. So I would say that there is chance that this > particular problem is gone. I monitor this further and I think that this > wasn't the only problem. But then it is another problem. > >> > >> Yeah, but not knowing your application load, 623, which would be about > 200 sockets (3 semaphores per sockets), is still a lot to be active at the > same time. Can you in some way invoke a full GC externally, like using > ZnReadEvalPrintDelegate and see if it eventually drops due to finalization > ? It should, at least that is what I see. > >> > > Yes, that's what I meant. There is always only one outgoing connection > at a time. Every 15 seconds one request is issued. So you see why expect > more to find. > > I'm travelling right now and will have a deeper look after being back > > > > Norbert > >>> Thanks to all of you who've helped solving this. If it comes to the VM > being the source of problems it is always extra annoying because it is way > harder to change something there. > >>> > >>> Norbert > >>> > >>> > >>> Am 08.10.2013 um 11:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >>> > >>>> > >>>> > >>>> > >>>> On 7 October 2013 18:36, Norbert Hartl <norbert(a)hartl.name> wrote: > >>>> > >>>> Am 07.10.2013 um 16:36 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >>>> > >>>>> 1 thing. > >>>>> > >>>>> can you tell me what given expression yields for your VM/image: > >>>>> > >>>>> Smalltalk vm maxExternalSemaphores > >>>>> > >>>>> (if it gives you number less than 10000000 then i think i know what > is your problem :) > >>>> It is 10000000 > >>>> > >>>> What would be the problem if it would be smaller? > >>>> > >>>> > >>>> that just means your VM don't have external object size cap. > >>>> I changed the implementation to not have hard limit (the arbitrary > large number > >>>> is there just to be "compatible" with previous implementation). > >>>> > >>>> This means, that you can actually change in your image the check and > completely ignore limits > >>>> and just keep growing if it necessary. > >>>> > >>>> Now, since you using VM which don't have a limit, but problem still > persists, > >>>> it seems like it somewhere else.. :/ > >>>>> i just found that after one merge, my changes get lost > >>>>> we're just plugged them back in, and it should be back again with > newer VMs.. > >>>>> but the problem could be more than just semaphores.. if merge broken > this, it may break > >>>>> many other things, so we need time to check > >>>> I try to look at it some more time. I'm using the pharo-vm from the > launchpad build. Are the changes supposed to be in this one? > >>>> > >>>> Norbert > >>>> > >>>> Launchpad? You mean ppa? I can't say i remember all the details how > changes to VM source > >>>> gets into ppa distro, and how fast they get there. @Damien, can you > enlighten us? > >>>> > >>>> > >>>> Well, the VM which i downloaded recently using zero-conf script, > having limit back to 256. Just some merge mistake, which now is fixed.. > means that couple builds will use limit-based implementation.. but then > >>>> it will be back to my implementaiton. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 7 October 2013 12:31, Norbert Hartl <norbert(a)hartl.name> wrote: > >>>>> > >>>>> Am 07.10.2013 um 11:28 schrieb Henrik Johansen < > henrik.s.johansen(a)veloxit.no>: > >>>>> > >>>>>> > >>>>>> On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert(a)hartl.name> > wrote: > >>>>>> > >>>>>>> As I need an image that runs longer than 24 hours I'm looking at > some stuff and wonder. Can anybody explain me the rationale for a code like > this > >>>>>>> > >>>>>>> maxExternalSemaphores: aSize > >>>>>>> "This method should never be called as result of normal program > >>>>>>> execution. If it is however, handle it differently: > >>>>>>> - In development, signal an error to promt user to set a bigger > size > >>>>>>> at startup immediately. > >>>>>>> - In production, accept the cost of potentially unhandled > interrupts, > >>>>>>> but log the action for later review. > >>>>>>> > >>>>>>> See comment in maxExternalObjectsSilently: why this behaviour is > >>>>>>> desirable, " > >>>>>>> "Can't find a place where development/production is decided. > >>>>>>> Suggest Smalltalk image inProduction, but use an overridable temp > >>>>>>> meanwhile. " > >>>>>>> | inProduction | > >>>>>>> self maxExternalSemaphores > >>>>>>> ifNil: [^ 0]. > >>>>>>> inProduction := false. > >>>>>>> ^ inProduction > >>>>>>> ifTrue: [self maxExternalSemaphoresSilently: aSize. > >>>>>>> self crTrace: 'WARNING: Had to increase size of > semaphore signal handling table due to many external objects concurrently > in use'; > >>>>>>> crTrace: 'You should increase this size at startup > using #maxExternalObjectsSilently:'; > >>>>>>> crTrace: 'Current table size: ' , self > maxExternalSemaphores printString] > >>>>>>> ifFalse: ["Smalltalk image" > >>>>>>> self error: 'Not enough space for external objects, set > a larger size at startup!' > >>>>>>> "Smalltalk image"] > >>>>>>> > >>>>>>> I have reported this once but got no feedback so I like to have a > few opinions. > >>>>>>> > >>>>>>> The report is here: https://pharo.fogbugz.com/f/cases/10839/ > >>>>>>> > >>>>>>> Norbert > >>>>>> > >>>>>> The rationale is that inProduction would be some global setting, > not yet in place when the code was writtenâ¦ > >>>>>> Excessive simultaneous Semaphore usage is something that should be > caught during development, in which case it's better to get an active > notification, than having it logged somewhere. > >>>>> > >>>>> Agreed. But didn't work in my case because it needed roughly 20 > hours and an instable remote backend to trigger the problem. And somehow I > forgot to install my logger as Transcript so there is no warning message. I > saw only dead images in the morning. > >>>>> This not satisfactory but on the other hand this type of problems > are hard to solve anyway. My feeling tells me there is more to discover. > Sockets resources get unregistered at finalization time but this didn't > work either. I would have said that the unlikely situation that no garbage > collection ran could be the case. But it can't because in > ExternalSemaphoreTable>>#freedSlotsIn:ratherThanIncreaseSizeTo: there is > explicit garbage collection. > >>>>> > >>>>>> If I've understood correctly, it's moot on newer Pharo VM's, where > there's no limit on the semtable size, but for legacy code a startup item > setting size using maxExternalObjectsSilently: (as suggested in the Warning > text), is still a more proper fix than setting inProduction to true and > crossing your fingers hoping no signals will be lost during table growth. > >>>>> > >>>>> Ah, I didn't know about the risk of loosing signals while resizing > the table. Thanks for that. Don't get me wrong I wasn't proposing to set > inProduction in effect. I don't think that automatically growing resource > management is a proper way to design a system. There is always a range of > resources you need for your use case. Not setting an upper bound for this > just covers leaking behavior. > >>>>> > >>>>> Norbert > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Best regards, > >>>>> Igor Stasenko. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Igor Stasenko. > >> > >> > > > > > -- Best regards, Igor Stasenko.

Oct. 12, 2013