- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Dirty Seaside-pharo-core and Seaside-pharo-core-backtracking

by Max Leske

If youâve loaded Seaside-Pharo then those extensions would be in the Seaside-Pharo package, wouldnât they? On 16.02.2014, at 14:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > When using the latest Seaside on Pharo 3 (either loading ConfigurationOfBootstrap or the Seaside image, 3.0 bleedingEdge, built on the pharo-contribution CI server), I have two mysterious dirty packages without a repository: > > - Seaside-pharo-core > - Seaside-pharo-core-backtracking > > These only contain extensions. There are no such Seaside package as far as I can see. > > What puzzles me is how the code got in the image in the first place: I can understand that these are possible wrong extension protocol names, but since they must be loaded by an MC package, how did they get into that package in the first place ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Feb. 16, 2014

List methods with problematic source

by Sebastian Sastre

Hi guys, How can I collect a list of methods with undefined classes in its source? Example: Iâve recently saw that Comanche http server had a package that wonât load in Pharo 3 because is using FileDirectory. Comanche now loads alright after a patch but.. Instead of iterating lazily this kind of problem in other packages, I would like to make a script that lists all this kind of cases in a given package. BTW a script like this would help to anticipate potential problems to other developers porting a product to Pharo When inspecting one of this methods Iâve sent #recompile to see if it raises an exception but it isnât. How can I perceive, using code, that a compiled method has this kind of problem? sebastian o/

Feb. 16, 2014

Dirty Seaside-pharo-core and Seaside-pharo-core-backtracking

by Sven Van Caekenberghe

When using the latest Seaside on Pharo 3 (either loading ConfigurationOfBootstrap or the Seaside image, 3.0 bleedingEdge, built on the pharo-contribution CI server), I have two mysterious dirty packages without a repository: - Seaside-pharo-core - Seaside-pharo-core-backtracking These only contain extensions. There are no such Seaside package as far as I can see. What puzzles me is how the code got in the image in the first place: I can understand that these are possible wrong extension protocol names, but since they must be loaded by an MC package, how did they get into that package in the first place ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 16, 2014

[pharo-project/pharo-core]

by GitHub

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

Feb. 16, 2014

[pharo-project/pharo-core] 79830b: 30764

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 79830bcb57fc1a6111dc1a622df50984671528a2 https://github.com/pharo-project/pharo-core/commit/79830bcb57fc1a6111dc1a62… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-02-16 (Sun, 16 Feb 2014) Changed paths: M RPackage-SystemIntegration.package/extension/RPackageOrganizer/instance/systemMethodRecategorizedActionFrom_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script417.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30764.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30764 12880 Monticello shows new class-side extension methods as local (i.e. not as extensions) https://pharo.fogbugz.com/f/cases/12880 http://files.pharo.org/image/30/30764.zip

Feb. 16, 2014

Re: [Pharo-dev] [GSoC ideas] Pharo - Derreferencer

by Levente Uzonyi

On Sat, 15 Feb 2014, Andres Valloud wrote: > All that I said was "it takes way more than 1 hour". > > The "useful" part comes in when e.g. "inboundPointers" reveals stuff that > should also be gone. So now you need a full blown reference finder, and > getting one of those to work quickly and correctly is not trivial. Also with That's not part of the project according to its description. Btw, PointerFinder and PointerExplorer are two tools which do exactly what you describe. > some objects you can't really do becomeForward: (or it won't help), e.g. with > a class (this would fall under the "reliably" category). "A problem with image based environment is, when you detect a memory leak is removing those objects from the system. This tool would provide a handy UI to inspect the current instances of the classes that we think they have a memory leak and, in case there are objects that are not being garbage collected, offer to the user a Derreference button. This is going to iterate over all the objects that have a reference to my object and remove that reference, finally enabling the Garbage Collector to get rid of the leak." This doesn't imply that the tool should save the user from doing bad things. It would be a impossible to avoid all cases anyway. > > We are all capable of writing random workspace code, I don't think this is > the idea for these projects. My concern was and is that writing a _tool_ (not a workspace script) that matches the GSoC project description is very easy. It takes an hour for an experienced user who knows what to do. So I don't see how could or why should a student spend a summer on it. Levente > > On 2/15/14 16:34 , Levente Uzonyi wrote: >> On Sat, 15 Feb 2014, Andres Valloud wrote: >> >>> FYI writing any decent production quality tool takes way more than 1 hour. >>> IME writing *two* reference finders, it takes a bunch of effort to make >>> them >>> work correctly, reliably, quickly, and in a useful way. >> >> I would agree with you if the building blocks weren't already in the >> image. >> >> Q: Which objects point to myObject? >> A: myObject inboundPointers >> >> Q: How can I dereference myObject? >> A: myObject becomeForward: nil >> >> Do you think it takes a summer to combine and extend these two lines into >> a tool? >> >> >> Levente >> >>> >>> On 2/15/14 6:31 , Alexandre Bergel wrote: >>>> Well... I do no think so. There is a fair amount of work regarding memory >>>> profiling. Dereferencing is probably only a small piece off. >>>> Anyway, we will have time to refine the project description >>>> >>>> Alexandre >>>> >>>>> Le 14-02-2014 Ã 18:17, Levente Uzonyi <leves(a)elte.hu> a Ã©crit : >>>>> >>>>>> On Fri, 14 Feb 2014, Alexandre Bergel wrote: >>>>>> >>>>>> Hi Paolo, >>>>>> >>>>>> I can mentor the project below: >>>>>>> Project idea >>>>>>> >>>>>>> Name: Instance Derreferencer for Pharo >>>>>>> Skill level: Intermediate >>>>>>> Possible Mentors: >>>>>>> Name of the Student: Alejandro Infante >>>>>>> >>>>>>> Description: >>>>>>> A problem with image based environment is, when you detect a memory >>>>>>> leak >>>>>>> is removing those objects from the system. This tool would provide a >>>>>>> handy UI to inspect the current instances of the classes that we think >>>>>>> they have a memory leak and, in case there are objects that are not >>>>>>> being garbage collected, offer to the user a Derreference button. This >>>>>>> is going to iterate over all the objects that have a reference to my >>>>>>> object and remove that reference, finally enabling the Garbage >>>>>>> Collector >>>>>>> to get rid of the leak. >>>>> >>>>> It shouldn't take more than an hour to implement such tool. >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2014-02-14 5:08 GMT-08:00 Nicolas Petton <petton.nicolas(a)gmail.com>: >>>>>>> >>>>>>> Paolo Bonzini writes: >>>>>>> >>>>>>>> Il 11/02/2014 10:42, Damien Cassou ha scritto: >>>>>>>>> Hi fellow Pharo hackers, >>>>>>>>> >>>>>>>>> ESUG, the European Smalltalk User Group, is applying for >>>>>>>>> this >>>>>>>>> year's Google Summer of Code. As you probably know, the >>>>>>>>> Summer >>>>>>>>> of Code provides the opportunity to fund students to work >>>>>>>>> during >>>>>>>>> the summer on Pharo. Please reply to this >>>>>>>>> email (be sure to use "Reply to all") if you have ideas you >>>>>>>>> would like to propose. >>>>>>>>> >>>>>>>>> Please include a summary of the project and links to web >>>>>>>>> pages >>>>>>>>> that can help prospective students to write their >>>>>>>>> application. >>>>>>>>> Please also include the following information: >>>>>>>>> >>>>>>>>> - if applicable, other dialects that you would be willing >>>>>>>>> to >>>>>>>>> mentor this project for >>>>>>>>> >>>>>>>>> - the skill level >>>>>>>>> >>>>>>>>> - name of the mentor(s), email addresses, and possibly any >>>>>>>>> IRC >>>>>>>>> network/channel/nickname where they can be found. >>>>>>>>> >>>>>>>>> Thanks for contributing to ESUG's Summer of Code >>>>>>>>> application! >>>>>>>> >>>>>>>> Just a note that I haven't yet processed this thread, but our ideas >>>>>>>> page >>>>>>>> is already looking pretty well (and Pharo section is big) so I'll >>>>>>>> probably do it in the weekend or next Monday. >>>>>>> >>>>>>> I can do it if you want. >>>>>>> >>>>>>> Cheers, >>>>>>> Nico >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>> >>> >>> >> >

Feb. 16, 2014

Re: [Pharo-dev] [GSoC ideas] Pharo - Derreferencer

by Andres Valloud

On 2/16/14 3:38 , Levente Uzonyi wrote: > On Sat, 15 Feb 2014, Alejandro Infante wrote: > >> Well, I tried today using that to release some memory used by >> Roassal. Let's say all the instances of ROElement. So I executed >> the following code: >> >> ROElement allInstances do: [:el | el becomeForward: nil ]. >> >> The next second the image crashed. Then I thought that was because >> the visualization was open. So I did another little experiment, >> closed the visualization, and then run the following code: >> >> ROElement allInstances do: [:el | el becomeForward: nil ]. >> "Everithing ok for now" Smalltalk garbageCollect. >> >> Again, same result, the image crashed. Also instead of doing >> garbage collect, I tried open the browser, but the image crashed >> just few seconds later. > > It's a sign of a bug either in the VM, or the finalization mechanism > (if these objects are subject to finalization), or Roassal itself. > You better examine the crash dumps. Yeah, who knows... maybe ROElement is dealing with FFI... It's way better to figure out why you have objects that won't go away, then you fix the real problem. Hopefully the scope for this GSoC project will be amended with those kinds of considerations in mind. Andres.

Feb. 16, 2014

Re: [Pharo-dev] [GSoC ideas] Pharo - Derreferencer

by Levente Uzonyi

On Sat, 15 Feb 2014, Alejandro Infante wrote: > Well, I tried today using that to release some memory used by Roassal. Let's say all the instances of ROElement. So I executed the following code: > > ROElement allInstances do: [:el | el becomeForward: nil ]. > > The next second the image crashed. Then I thought that was because the visualization was open. So I did another little experiment, closed the > visualization, and then run the following code: > > ROElement allInstances do: [:el | el becomeForward: nil ]. > "Everithing ok for now" > Smalltalk garbageCollect. > > Again, same result, the image crashed. Also instead of doing garbage collect, I tried open the browser, but the image crashed just few seconds > later.Â It's a sign of a bug either in the VM, or the finalization mechanism (if these objects are subject to finalization), or Roassal itself. You better examine the crash dumps. > > At least (in my opinion), building a reliable tool that can crash your image easily is not 1 hour work, nor 1 week work. Not crashing the VM is not part of the GSoC project description, and there's a good reason for that. No tool can save you from a VM crash. You can avoid some cases, but not all. Using a dereferencer means taking the easy but risky way of getting rid of unnecessary objects. Levente > > Cheers, > Alejandro > > > > 2014-02-15 16:34 GMT-08:00 Levente Uzonyi <leves(a)elte.hu>: > On Sat, 15 Feb 2014, Andres Valloud wrote: > > FYI writing any decent production quality tool takes way more than 1 hour. IME writing *two* reference finders, it takes a > bunch of effort to make them work correctly, reliably, quickly, and in a useful way. > > > I would agree with you if the building blocks weren't already in the image. > > Q: Which objects point to myObject? > A: myObject inboundPointers > > Q: How can I dereference myObject? > A: myObject becomeForward: nil > > Do you think it takes a summer to combine and extend these two lines into a tool? > > > Levente > > > On 2/15/14 6:31 , Alexandre Bergel wrote: > Well... I do no think so. There is a fair amount of work regarding memory profiling. Dereferencing is probably only > a small piece off. > Anyway, we will have time to refine the project description > > Alexandre > > Le 14-02-2014 Ã 18:17, Levente Uzonyi <leves(a)elte.hu> a Ã©crit : > > On Fri, 14 Feb 2014, Alexandre Bergel wrote: > > Hi Paolo, > > I can mentor the project below: > Project idea > > Name: Instance Derreferencer for Pharo > Skill level: Intermediate > Possible Mentors: > Name of the Student: Alejandro Infante > > Description: > A problem with image based environment is, when you detect a memory leak is > removing those objects from the system. This tool would provide a handy UI to > inspect the current instances of the classes that we think they have a memory > leak and, in case there are objects that are not being garbage collected, offer > to the user a Derreference button. This is going to iterate over all the objects > that have a reference to my object and remove that reference, finally enabling > the Garbage Collector to get rid of the leak. > > > It shouldn't take more than an hour to implement such tool. > > > Levente > > > Cheers, > Alexandre > > > > > > 2014-02-14 5:08 GMT-08:00 Nicolas Petton <petton.nicolas(a)gmail.com>: > > Paolo Bonzini writes: > > Il 11/02/2014 10:42, Damien Cassou ha scritto: > Hi fellow Pharo hackers, > > Â Â Â Â ESUG, the European Smalltalk User Group, is > applying for this > Â Â Â Â year's Google Summer of Code. Â As you probably > know, the Summer > Â Â Â Â of Code provides the opportunity to fund > students to work during > Â Â Â Â the summer on Pharo. Â Please reply to this > Â Â Â Â email (be sure to use "Reply to all") if you > have ideas you > Â Â Â Â would like to propose. > > Â Â Â Â Please include a summary of the project and > links to web pages > Â Â Â Â that can help prospective students to write > their application. > Â Â Â Â Please also include the following information: > > Â Â Â Â - if applicable, other dialects that you would > be willing to > Â Â Â Â Â mentor this project for > > Â Â Â Â - the skill level > > Â Â Â Â - name of the mentor(s), email addresses, and > possibly any IRC > Â Â Â Â Â network/channel/nickname where they can be > found. > > Â Â Â Â Thanks for contributing to ESUG's Summer of Code > application! > > > Just a note that I haven't yet processed this thread, but our ideas > page > is already looking pretty well (and Pharo section is big) so I'll > probably do it in the weekend or next Monday. > > > I can do it if you want. > > Cheers, > Nico > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

Feb. 16, 2014

Enhancement - single operation revert to last saved image

by Ben Coman

Just a passing thought... as I am debugging, sometimes just before entering a step that I know is going to screw up the state of things, I save the image so that I can exit and restart to get back to that point. Now rather than having to manually quit & restart, a command "revert to last saved image" which did the quit & restart in one operation would be really nice. How doable would that be? cheers -ben

Feb. 16, 2014

Re: [Pharo-dev] Please add me as a contributor to PharoExtras/XMLWriter

by Damien Cassou

On Sat, Feb 15, 2014 at 4:10 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > I'd like to add a #stable: method to the configuration done -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 16, 2014