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

Re: [Pharo-dev] 2 seconds default time limit for tests

by stepharong

On Thu, 16 Feb 2017 14:46:41 +0100, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Thu, Feb 16, 2017 at 2:31 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >> 2017-02-16 13:49 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> I vote for not introducing during code-freeze. >> >> I understand it but these behaviour was introduced in Pharo 6. And It >> is already used quite long time. So it could be considered as small >> improvements to already integrated feature. >>> >>> We can discuss it for Pharo 7, I'm not against actually. But I have >>> some concerns: >>> >>> - How does it work when we are debugging? >>> I mean, imagine I'm running a test, a debugger is open, and I start >>> working on it. How do these timeout currently work in this scenario? I >>> imagine that the test runner should detect you entered >>>into a "I'm >>> debugging" mode and should not kill your test, but this >> >> It solved very easily. "Watchdog process" just checks that test process >> isSuspended or not. If it is not suspended timeout is signalled. Test >> process is suspended only when debugged. > > Ok. Is something like this in a class comment? If not, we could add it, > because it will get lost in the mails. + 10000 > >> >>> is not clear to me how this works right now. >>> >>> - Also, how can we better document these things? Because I was bitten >>> a couple of times by this timeouts and the "I kill your process but I >>> do not tell you", and it was not nice because it was >>>completely >>> silent or obscure. >> >> Things which you show me I improved. Last days I fix Christophe issues >> which was really important. Anyway "fork management in tests" is not >> related to time limit of tests. And of course it is not >>supposed to >> make troubles but instead it should make life easy :) > > I know, I'm not pleading for improvements :). Just talking about > documenttion here. -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 17, 2017

Re: [Pharo-dev] 2 seconds default time limit for tests

by Denis Kudriashov

I moved issue to Pharo 7 2017-02-16 13:33 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > In Pharo 6 we introduced time limit for tests. Currently it is set to 1 > minute by default. And concrete test cases or single tests can redefine it > with suitable value. There is also setting to change default limit globally > which should help to not adopt external projects immediately if current > limit is bad for them. > > There is issue 19105 > <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests-should…> to > make limit really small. It will set default limit for 2 seconds. Slow > tests are already marked with bigger value. So it is safe for integration > > Here I ask for your agreement with this change. Or disagreement if there > are good reasons to not do this. > > I hope following story will convince you that default time limit should be > small: > > I worked on tests for new project and I got hanging tests. These tests > were waiting for some event which not happens because of bugs. They will be > failed after 1 minutes due to timeout. > > But when you work on code you of course do not want to wait 1 minute. So > it always forces manual interrupt of running tests. But then you could not > run full test suite to see all problem tests. And also it is not really > easy to detect current running test after interrupt. You need analyze stack > in debugger and if you just close debugger information is lost. > > So to fix it I change default timeout in each of my test cases. > If you will work on similar code you will need same approach to > comfortably detect and fix "synchronization" bugs. > > So this was my story. I am sure default behaviour with small time limit > will make SUnit much better. > Common case is that unit tests are supposed to be fast. Users expect it by > default. And if something is going wrong fast tests should fail fast. > When user wrote slow test it is expected to know that test is slow. And > for such rare cases user can mark slow tests explicitly. But SUnit should > not expect tests to be slow by default. > > I think it is really good improvement for Pharo 6. It makes TDD in Pharo > better. > > Best regards, > Denis >

Feb. 17, 2017

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