- Pharo-dev - lists.pharo.org

[Pharo-project] Help with a WeakOrderedCollection and objects not being GCed

by Mariano Martinez Peck

Hi guys. I am since yesterday trying to find something and I cannot. So at this point I need external eyes :) I have this little code: anObject := ClassWith2Var new. sharedObject := ClassWith1Var new. sharedObject var1: 'nose'. anObject var1: Date today. anObject var2: sharedObject. serializedObjects := FuelMareaSerializer new serializeAndWriteObject: anObject to: 'aFileName'. anObject := nil. sharedObject := nil. 3 timesRepeat: [Smalltalk garbageCollect]. serializedObjects inspect. What is important here is that FuelMareaSerializer new serializeAndWriteObject: anObject to: 'aFileName' answers a WeakOrderedCollection with each object of the serialized graph (taking anObject as the root) Now, if I print the tempVar serializedObjects I see: a WeakOrderedCollection(ClassWith1Var ClassWith2Var Date DateAndTime Duration a ClassWith1Var a ClassWith2Var 3 August 2011 2011-08-03T00:00:00+02:00 0:02:00:00 1:00:00:00 86400 2455777 'nose' 0 7200) WHYYYY?? why are all there if I put a nil to both, anObject and sharedObejct. This WeakOrderedCollection should be with all nils (except classes). Why are not being garbage collected? If I explore, for example the tempVar sharedObejct, which is at serializedObjects at: 6 and then I put explore pointers I ONLY see the array of the WeakOrderedCollection pointing to it. I don't understand. Any help is really appreaciated. -- Mariano http://marianopeck.wordpress.com

Aug. 3, 2011

Re: [Pharo-project] Small Seaside image

by Marcus Denker

On Aug 3, 2011, at 10:17 AM, laurent laffont wrote: > Hi, > > actually using PharoCore 1.3, loading ConfigurationOfSeaside30 Core, then ScriptLoader>>cleanUpForProduction I have a 13MB image. Is it possible to have it smaller ? (I know a next step is to be able to use PharoKernel). cleanUpForProduction should result in a Core image that is just 6.5MB... so the ConfigurationOfSeaside30 seems to load *a lot* of stuff? Maybe be a bit selective? Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 3, 2011

[Pharo-project] [update 1.4] #14073

by Marcus Denker

14073 ----- Issue 4574: ChangedMessageSet is not referenced http://code.google.com/p/pharo/issues/detail?id=4574 Issue 4569: load updates just loads the last update? http://code.google.com/p/pharo/issues/detail?id=4569 -- Marcus Denker -- http://marcusdenker.de

Aug. 3, 2011

[Pharo-project] Small Seaside image

by laurent laffont

Hi, actually using PharoCore 1.3, loading ConfigurationOfSeaside30 Core, then ScriptLoader>>cleanUpForProduction I have a 13MB image. Is it possible to have it smaller ? (I know a next step is to be able to use PharoKernel). Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

Aug. 3, 2011

Re: [Pharo-project] building from PharoKernel

by Pavel Krivanek

I will look at it but today I'm not neer my computer -- Pavel 2.8.2011 v 23:15, laurent laffont <laurent.laffont(a)gmail.com>: > Is it actually possible to load ConfigurationOfSeaside30 in PharoKernel ? > > I've tried using https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Gofer/6/artifact/Pharo… but it seems to do nothing... > > Note that builds #7 and #8 .zip seem to contain a PharoCore and not PharoKernel. > > Laurent > > On Tue, Aug 2, 2011 at 11:08 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > We still do not have MinimalMorphic image equivalent so there is no > reason to use it for DrGeo. However you may try to create DrGeo image, > then start with Gefer image, load all methods that are not present in > the Gofer image in form of a proxy method that will log the method > call, loads the right code and executes it. Some supporting code is on > the wiki of http://www.squeaksource.com/KernelImage.html. > MinimalMorphic was created partly using this way. > > -- Pavel > > On Tue, Aug 2, 2011 at 3:41 PM, Hilaire Fernandes > <hilaire.fernandes(a)edu.ge.ch> wrote: > > I would like to build a DrGeo image from PharoKernel. Is it something > > possible? I guess I am not the only one wondering about that > > > > Hilaire > > > > > > -- > > Education 0.2 -- http://blog.ofset.org/hilaire > > > > > > > >

Aug. 3, 2011

Re: [Pharo-project] Inspector limiting an object printString output

by Tudor Girba

+1 Doru On 3 Aug 2011, at 06:10, Igor Stasenko wrote: > In > > Inspector>>selectionPrintString it uses: > > text := [self selection printStringLimitedTo: 5000] > > which sometimes not quite adequate (sometimes i need to display more). > > I think it would be nicer if inspector would ask object, if it desires > to limit itself (when printing in big inspection pane) > and what concrete limit it desires, instead of hardcoding the number > in inspector. > > Something like: > > Object>>printStringLimited > ^ self printLimit ifNotNil: [:limit | > self printStringLimitedTo: limit ] > ifNil: [ > self printString ]. > > so, then #printLimit could be overridden by choice of developer, to > set (or not) the limits > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Aug. 3, 2011

[Pharo-project] Inspector limiting an object printString output

by Igor Stasenko

In Inspector>>selectionPrintString it uses: text := [self selection printStringLimitedTo: 5000] which sometimes not quite adequate (sometimes i need to display more). I think it would be nicer if inspector would ask object, if it desires to limit itself (when printing in big inspection pane) and what concrete limit it desires, instead of hardcoding the number in inspector. Something like: Object>>printStringLimited ^ self printLimit ifNotNil: [:limit | self printStringLimitedTo: limit ] ifNil: [ self printString ]. so, then #printLimit could be overridden by choice of developer, to set (or not) the limits -- Best regards, Igor Stasenko AKA sig.

Aug. 3, 2011

Re: [Pharo-project] [squeak-dev] something we lost with events [was Optimizing RunArray]

by Igor Stasenko

On 3 August 2011 03:00, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I've got the feeling that we've lost one feature: > > When you're typing super fast, characters would be inserted several at > once in a st80 ParagraphEditor > That typically happens when the displaying or more probably the > paragraph re-composition is slow. > The composition/display cycle would occur after first key - giving the > impression of a non responsive UI - but then consecutive key strokes > would flow all in once thanks to the while loops in #readKeyboard and > the buffered Queue of events. > > Not the most interactive UI ever, but now things are worse with > current event implementation. > There is a one by one keystroke / composition / display, and the > result is a less responsive UI than polling ! > If you edit a Smalltalk method, no problem, but try editing your 45 > MByte change log just to see how deadly it feels, super fast means 0.2 > Hz on my machine. > > I wonder how we could restore this feature... > My take is that we should optimize Text data structure for editing. Because right now, its contents are stored in a single blobby string. And every time you modifying it, you have to create new string.. which consuming a lot of energy when you editing 45Mbytes :) > Nicolas > -- Best regards, Igor Stasenko AKA sig.

Aug. 3, 2011

Re: [Pharo-project] Disable the debugger

by Igor Stasenko

On 2 August 2011 22:04, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > would be nice to have a class responsible for that and that slowly we get a complete system ready for this kind of deployement > I think best would be to adopt this with Pharo-Kernel , since it unloads a lot of stuff and knows how to do that w/o errors. Maybe adding option(s) there like "strip dev tools" would be nice. > Stef > > On Aug 2, 2011, at 7:06 PM, Mariano Martinez Peck wrote: > >> Check in older Pharo images like 1.1.1 all the stuff in #disableProgrammerFacilities >> >> >> disableProgrammerFacilities >> Â Â "Warning: do not call this lightly! Â It disables all access to menus, debuggers, halos. Â There is no guaranteed return from this, which is to say, you cannot necessarily reenable these things once they are disabled -- you can only use whatever the UI of the current project affords, and you cannot even snapshot -- you can only quit. >> >> Â Â Â You can completely reverse the work of this method by calling the dual Preferences method enableProgrammerFacilities, provided you have left yourself leeway to bring about a call to that method. >> (does not reverse the ToolSet registrations) >> >> Â Â To set up a system that will come up in such a state, you have to request the snapshot in the same breath as you disable the programmer facilities. Â To do this, put the following line into the 'do' menu and then evaluate it from that 'do' menu: >> >> Â Â Â Â Â Preferences disableProgrammerFacilities. >> >> You will be prompted for a new image name under which to save the resulting image." >> Â Â self deprecated: 'No replacement for now'. >> >> Â Â Beeper beep. >> Â Â (self >> Â Â Â Â confirm: 'CAUTION!! >> This is a drastic step! >> Do you really want to do this?') >> Â Â Â Â Â Â ifFalse: >> Â Â Â Â Â Â Â Â [Beeper beep. >> Â Â Â Â Â Â Â Â ^self inform: 'whew!']. >> Â Â self disable: #cmdDotEnabled. Â Â "No user-interrupt-into-debugger" >> Â Â self disable: #editableStringMorphs. "turn off shift-click editing" >> Â Â ToolSet registeredClasses copy do: [:c | ToolSet unregister: c]. >> Â Â ToolSet default: nil. "unregister and make sure default is nil to really prevent debug windows" >> Â Â Â Â "also now takes care of low space watcher interrupts" >> Â Â self compileHardCodedPref: #cmdGesturesEnabled enable: false. Â Â "No halos, etc." >> Â Â self compileHardCodedPref: #cmdKeysInText enable: false. Â Â "No user commands invokable via cmd-key combos in text editor" >> Â Â self enable: #noviceMode. Â Â "No control-menu" >> Â Â self disable: #warnIfNoSourcesFile. >> Â Â self disable: #warnIfNoChangesFile. >> Â Â Smalltalk saveAs >> >> On Tue, Aug 2, 2011 at 5:59 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: >> Hi, >> >> is it possible to disable the debugger in a Seaside image for production ? >> >> Laurent Laffont - @lolgzs >> >> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >> Blog: http://magaloma.blogspot.com/ >> Developer group: http://cara74.seasidehosting.st >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 3, 2011

[Pharo-project] something we lost with events [was Optimizing RunArray]

by Nicolas Cellier

I've got the feeling that we've lost one feature: When you're typing super fast, characters would be inserted several at once in a st80 ParagraphEditor That typically happens when the displaying or more probably the paragraph re-composition is slow. The composition/display cycle would occur after first key - giving the impression of a non responsive UI - but then consecutive key strokes would flow all in once thanks to the while loops in #readKeyboard and the buffered Queue of events. Not the most interactive UI ever, but now things are worse with current event implementation. There is a one by one keystroke / composition / display, and the result is a less responsive UI than polling ! If you edit a Smalltalk method, no problem, but try editing your 45 MByte change log just to see how deadly it feels, super fast means 0.2 Hz on my machine. I wonder how we could restore this feature... Nicolas

Aug. 3, 2011