- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Code Completion in Pharo

by stepharong

Hi lukas Nice to see you here. I would start to look at the code and clean what is strange. - Did you test the difference between the two algorithms? - Did you play with NECPreferences? - I would like to see what is the difference between the NOC class and the NECclass - I would like to remove the link with Smalltalk tools - I would be nice to improve the class comments. - there are some tests for NEC but -- are there any good? Did you read them? - there are no tests for NOC -- it would be nice to add tests. Looking at the code quickFillWithCategoriesMatching: pattern (Smalltalk organization categoriesMatching: pattern) do: [:category | (Smalltalk organization classesInCategory: category) do: [:e | self quickFillWithClass: e]] >> Smalltalk globals organization no senders? Remove? Class categories are an obsolete concepts so we should clean this. NOCompletionTable comment I keep track of symbols to be retrieved in ocompletion algorithm. Unlike ecompletion, I learn something and try to retrieve users last occurences of typing sequences first, then the system symbols which match. TODO remove stupid symbols (like packages and method extensions and timestamp) > Hello to all, > > I am a student at the Faculty of Information Technology of the Czech > Technical University in Prague and I decided to make Code Completion in > Pharo the topic of my Bachelor's degree and try to >improve it. > > If you have suggestions on what should change / how to change it so you > would be satisfied with it, I will appreciate any input on this topic. > It would mean a lot to me if you could find two minutes >and take this > survey (there are only like 7 questions, so it won't take longer than > those 2 minutes): > > https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwRsnA_AX_e_7sZEz2… > > Regards > > > Lukas -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 17, 2017

Re: [Pharo-dev] debugger evaluator tab for temporary variables

by Denis Kudriashov

2017-02-17 10:36 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Seems like you misread my idea (3am syndrome again?) > You wouldn't need to select "self". > The idea is in the first (left hand) pane you would flip from the > [Variables] to an [Evaluator] tab > this hiding all variables but having access to all the same ones from > the [Evaluator] tab. > Ok, I see :)

Feb. 17, 2017

Re: [Pharo-dev] debugger evaluator tab for temporary variables

by Ben Coman

On Fri, Feb 17, 2017 at 4:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-02-17 3:01 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> A minor irritation with the debugger is that the [Evaluator] tab is >> only for the object of the selected instance variable. > > > Evaluator appears only when you select something in table. It could be any > object which can have inst vars with same names as temps. > Do you wan't this behaviour when "self" is selected? > In that case newbies can ask why temps are not available when other objects > are selected. Seems like you misread my idea (3am syndrome again?) You wouldn't need to select "self". The idea is in the first (left hand) pane you would flip from the [Variables] to an [Evaluator] tab this hiding all variables but having access to all the same ones from the [Evaluator] tab. On Fri, Feb 17, 2017 at 3:58 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Please open an issue for this and add Andrei and I to it. https://pharo.fogbugz.com/f/cases/19720/Add-method-scoped-Evaluator-tab-to-… cheers -ben

Feb. 17, 2017

Re: [Pharo-dev] debugger highlighting objects up the stack

by Denis Kudriashov

2017-02-17 2:41 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Just a brief throw away idea to share before it floats off on its own, > it could be useful from the debugger being able to select a variable, > and for the object it contains, ask the debugger to highlight up the stack > where that object exists in variables and in code. > Could be complicated - may need to: > * autoscroll the debugger's inspector pane > * annotate previously sent messages with the identity hash of the > object returned > Yes, I like it. At least debugger could select variable in table when it is selected in source code. And also with hover event with returning back when mouse is leave.

Feb. 17, 2017

Re: [Pharo-dev] debugger evaluator tab for temporary variables

by Denis Kudriashov

2017-02-17 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Do you won't Ah, I still sleep. Do you want? :)

Feb. 17, 2017

Re: [Pharo-dev] debugger evaluator tab for temporary variables

by Denis Kudriashov

2017-02-17 3:01 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > A minor irritation with the debugger is that the [Evaluator] tab is > only for the object of the selected instance variable. > Evaluator appears only when you select something in table. It could be any object which can have inst vars with same names as temps. Do you won't this behaviour when "self" is selected? In that case newbies can ask why temps are not available when other objects are selected.

Feb. 17, 2017

Re: [Pharo-dev] debugger evaluator tab for temporary variables

by Tudor Girba

Good point. Please open an issue for this and add Andrei and I to it. Cheers, Doru > On Feb 17, 2017, at 3:01 AM, Ben Coman <btc(a)openInWorld.com> wrote: > > A minor irritation with the debugger is that the [Evaluator] tab is > only for the object of the selected instance variable. > > IIUC, to write a snippet of code using a local variable you must edit > the code of the method, which dirties it. I've lived with this, but > thinking of newcomer first impressions for Pharo 6, an [Evaluator] tab > next to the existing [Variables] tab with access to the whole method > scope would be really nice. > > cheers -ben > -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Feb. 17, 2017

Re: [Pharo-dev] Pharo Papers

by Serge Stinckwich

Yes definitively will be nice to have a list of research about Pharo or based on Pharo. Thank you Marcus. On Thu, Feb 16, 2017 at 3:13 PM, denker <marcus.denker(a)inria.fr> wrote: > One idea on my TODO that I got from colleagues here working on another > OpenSource/Research > system (Sofa3D): to add all publication to the website automatically using > HAL (the national french > paper database). > > It looks like this on the website: > https://www.sofa-framework.org/applications/publications/ > > and here âhow to add a paperâ: > > https://www.sofa-framework.org/applications/publications/add-a-publication-… > > I will definitely set this up for Pharo later this year (read: as soon as > possible) > > Marcus > > > On 16 Feb 2017, at 14:30, Ben Coman <btc(a)openinworld.com> wrote: > > And now for your regularly scheduled random trivia show... > I was mildly curious about how many papers touched on Pharo. > > 1,110 on google scholar for... > "pharo" "programming" > http://tiny.cc/pharo-scholar > > 1,630 on normal google for... > "pharo" "programming" "abstract" "introduction" "conclusion" > "references" filetype:pdf > http://tiny.cc/pharo-papers > > Probably a lot of overlap between them. > cheers -ben > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 17, 2017

Re: [Pharo-dev] Pharo Papers

by denker

> On 16 Feb 2017, at 23:58, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > But you will not get the papers not stored on HAL. And I suspect there are more papers about Pharo outside the HAL world. > Hal is a public archive. So the idea would be that if you want you paper listed, add it to HAL. (you would need to add it (or its meta-data) somewhere, so why not use this infrastructure). Marcus

Feb. 17, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by ClÃ©ment Bera

On Thu, Feb 16, 2017 at 6:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks, ClÃ©ment, for this update, really exciting news. Is the new GC > faster too ? > The full GC is indeed much faster as the previous compaction algorithm was very slow. But unless you were executing memory intensive code in very large heaps, you won't see much difference as full GC are uncommon. We still need to make the GC incremental to avoid pauses ... > > On 16 Feb 2017, at 17:16, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > Hi all, > > > > A temporary solution had been integrated in the VM a year ago, but only > part of the problem was solved. > > > > This issue has been entirely solved in the VM through the implementation > of a new compactor for the full GC. The new compactor (called the planning > compactor) has been marked as the default full GC compactor for further VM > builds yesterday, replacing the existing Pig compactor. However it seems > that the new compactor has not yet passed all the validation infrastructure > (several builds are currently marked as 'error'). > > > > I would expect VM builds in the incoming days to feature the new > compactor. This problem should therefore be solved very soon in the latest > pharo VMs. > > > > In any case, this problem does not require any image-side changes. It > will be in Pharo 6 if the Pharo 6 release VM features the new compactor. > > > > Best, > > > > Clement > > > > On Thu, Feb 16, 2017 at 4:26 PM, denker <marcus.denker(a)inria.fr> wrote: > > > > > On 16 Feb 2017, at 16:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > > >> On 16 Feb 2017, at 16:16, denker <marcus.denker(a)inria.fr> wrote: > > >> > > >> No, > > >> > > >> Our image is not 47 MBâ¦ more like 28. > > >> > > >> My understanding is: > > >> -> Cog works with âpagesâ (is that the term?) of memory. > > >> -> if a page is empty, it gets cleaned up and does not cost > space when saving. > > >> -> if there is some object still allocated, the whole page will > be saved (partly empty) > > >> > > >> Not sure if that is completely right, but it explains why the image > with > > >> lots of objects allocated new can shrink again, while the 47MB never > shrinks, even though the > > >> image for sure is much smaller. > > >> > > >> => what is missing is a âcleanupâ phase that sweeps together all the > half-empty pages. > > >> > > >> What is fun is that we now ship a 47MB image and nobody ever > complains. (or even asks) > > > > > > Yeah, that proves it is not such a big deal, today. > > > But still, we have to fix this discrepancy between 28 and 47. > > > > > > > > > As I tried to explain: the VM is missing a âcondenserâ that cleans up > half allocated pages. > > > > > Is the 'release cleanup' done on this image each time ? > > > > Yes. > > > > Marcus > > > > >

Feb. 17, 2017