February 2014 - Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] [Seaside] Handling of $+ in URLs

by Johan Brichau

Sven, once again many thanks for addressing this is in such a swift manner! On 15 Feb 2014, at 23:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Johan Brichau reported an issue a couple of days ago concerning the handling of $+ in ZnUrl (Pharo 3's URL class) and in Seaside's WAUrl. #bleedingEdge of Zinc HTTP Components fixes the issue, as far as I can see. I want to explain the problem and the solution. > > Before october 24 of last year, ZnUrl used a 'better safe than sorry' safe set when doing percent encoding of unsafe characters. However, the URL spec defines different allowed characters per URL part. This behaviour was then added to Zinc-Resource-Meta-Core, ZnUrl's package. > > Soon after that a discussion with Jan van de Sandt let to a first small change: since ZnUrl interprets the query part of a URL as key-value pairs, it is necessary to treat $= and $& as unsafe, even though they are not according to the URL spec (which doesn't concern itself with how the query part is interpreted). > > All that time, $+ kept on being interpreted as a space, independent of the safe set. As Johan reported, this conflicted with $+ being a safe character. Which eventually let to the functional problem of not being able to enter a + in an input field, in Seaside. > > Why only in Seaside ? Because ZnZincServerAdaptor>>#requestUrlFor: was implemented by printing the interpreted incoming ZnUrl and parsing it again. There, the escaping of $+ disappeared and it became an unintended space. > > This situation is now fixed by > > Changes to ZnPercentEncoder: > - adding an #decodePlusAsSpace boolean option > > Changes to ZnResourceMetaUtils: > - #decodePercent: no longer decodes plus as space > - #decodePercentForQuery: does plus as space decoding > - #queryKeyValueSafeSet no longer includes $+ > - #parseQueryFrom: not uses #decodePercentForQuery: > > Added ZnDefaultServerDelegate>>#formTest1: to test simple form submit encoding handling > > Modify ZnZincServerAdaptor>>#requestUrlFor: to build a WAUrl explicitely from the interpreted parts of the incoming ZnUrl instead of going via printing and parsing > > Adding new unit tests > - ZnUrlTests>>#testPlusHandling > - ZnServerTests>>#testFormTest1 > > I think WAUrl should best be changed as well, but that is not my call. > > In code, this summarises the implemented behaviour: > > ZnUrlTests>>#testPlusHandling > "While percent decoding, a + is translated as a space only in the context of > application/x-www-form-urlencoded get/post requests: > http://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www-form-… > ZnUrl interprets its query part as key value pairs where this translation is applicable, > even though strictly speaking + (and =, &) are plain unreserved characters in the query" > > "$+ is not special in the path part of the URL and it remains itself" > self > assert: 'http://localhost/foo+bar' asZnUrl firstPathSegment > equals: 'foo+bar'. > self > assert: 'http://localhost/foo+bar' asZnUrl printString > equals: 'http://localhost/foo+bar'. > "$+ gets decoded to space in the interpreted query part of the URL, > and becomes an encoded space if needed" > self > assert: ('http://localhost/test?q=foo+bar' asZnUrl queryAt: #q) > equals: 'foo bar'. > self > assert: 'http://localhost/test?q=foo+bar' asZnUrl printString > equals: 'http://localhost/test?q=foo%20bar'. > "to pass $+ as $+ in a query, it has to be encoded" > self > assert: 'http://localhost/test?q=foo%2Bbar' asZnUrl printString > equals: 'http://localhost/test?q=foo%2Bbar' > > I hope this is a good and correct solution. In any case, it fixes the functional problem that $+ disappeared in WAUrlEncodingFunctionalTest - which I took over in ZnDefaultServerDelegate>>#formTest1: > > Thanks Johan for the whole discussion ! > > Sven > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Feb. 16, 2014

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

by Andres Valloud

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 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). We are all capable of writing random workspace code, I don't think this is the idea for these projects. 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 Alejandro Infante

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. At least (in my opinion), building a reliable tool that can crash your image easily is not 1 hour work, nor 1 week work. 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

Re: [Pharo-dev] Fwd: Request

by Levente Uzonyi

On Sat, 15 Feb 2014, Guido Chari wrote: > Thanks Olivier i will try with it for sure. > Thanks ben! i will procrastinate with the game too :P... > > Levente, i'm working in a Slang compiler at language side that generates assembly that is run then with nativeboost. Then primitives could be > changed, compiled individually, and run at runtime. that's what i call dynamic primitives. Cool! Levente > > > 2014-02-14 20:10 GMT-03:00 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 13 Feb 2014, Guido Chari wrote: > > > Hi guys, > IÂ´m doing some experiments with dynamic primitives and files.Â > > > What's a dynamic primitive? > > > Levente > > > Actually i am working with the socket and file plugin. (In that order of priority) > > Does anyone know about an open pharo app that make heavy use of sockets (mainly creating lot) that i can borrowed (install > locally) for doing serious experiments? Something with heavy used of files will help > too. > > Thanks, > Best, > Guido. > > > > >

Feb. 16, 2014