September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] could we discuss 19006

by monty

It doesn't add any new streams or other classes besides a test case. AbstractBinaryStream was already there. It just adds #sync to the FileSysteam API and legacy file streams, recategorizes many stream methods to make them more consistent, fixes #flush to fail when the primitive does (the correct behavior-read the comment!), and adds tests for WriteStream and LimitedWriteStream. The #sync addition on Unix uses ffsync(), while #flush uses fflush(). Why is #sync needed if we have #flush? From `man fflush`: > Note that fflush() flushes only the user-space buffers provided by the > C library. To ensure that the data is physically stored on disk the > kernel buffers must be flushed too, for example, with sync(2) or > fsync(2). (but on Windows they're implemented identically) > Sent: Saturday, September 03, 2016 at 3:34 PM > From: stepharo <stepharo(a)free.fr> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] could we discuss 19006 > > Hi guys > > The change 19006 is adding a lot of streams AbstractBinaryStream and I > do not really get the vision. > > Note that I'm not against. I just want to understand. > > Do we add these and remove some old ones? > > What is sync? > > Ideally I would like to throw away all the streams and use xtreams instead. > > So thanks for your time explaining us the idea. > > > Stef > > > > >

Sept. 4, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Denis Kudriashov

2016-09-03 19:11 GMT+02:00 Paul DeBruicker <pdebruic(a)gmail.com>: > Oh wait I see in the first message in this thread you have > > self timeLimit: 10 seconds > yes

Sept. 3, 2016

Message browser strange new behavior

by stepharo

Hi Often I look at senders and I modify them directly in the message browser and I do not one by one. Now when I recompile a method I get a new one and I lose the next one. Am I the only one to have this behavior. It is highly disrputing. Stef

Sept. 3, 2016

pillar ast & tokens

by Tudor Girba

Hi, I am reviewing the Pillar PetitParser. Nice work! I would like to use the AST that comes out of it for creating a highlighter. To this end, I would need the range in the original source of an AST node. For example, to highlight a script, I would need to know where it starts and where it ends. This information is available in the parser, but I noticed that the AST does not preserve the original tokens (or at least the source range). Is there any reason for it? If no, is there are any plan to add these tokens to the AST? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

Sept. 3, 2016

could we discuss 19006

by stepharo

Hi guys The change 19006 is adding a lot of streams AbstractBinaryStream and I do not really get the vision. Note that I'm not against. I just want to understand. Do we add these and remove some old ones? What is sync? Ideally I would like to throw away all the streams and use xtreams instead. So thanks for your time explaining us the idea. Stef

Sept. 3, 2016

Re: [Pharo-dev] Idea: User-Installed Nautilus Package Group

by stepharo

There was a smart group with all recent packages and nobody used them. So if you want to add a group with the functionality you need go ahead. What we could do is mark all the present packages only display a diff after loading. I would like to have a different group behavior such as only showing the classes I want to see. But this is work. First what is really annoying to me is the fact that when I'm in hierarchy I cannot select a package to switch to the view package. This is the first thing I want to fix. Stef > I've often wanted to know which packages I had personally installed in an > image (i.e. non-kernel). Our one-level-deep package nesting makes the full > list unnavigable, so how about a Nautlius group where all new packages get > included automatically? We could clear it out prior to release et voila! > > What do you think? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Idea-User-Installed-Nautilus-Package-Group-tp4913942.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 3, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Paul DeBruicker

Oh wait I see in the first message in this thread you have self timeLimit: 10 seconds Paul DeBruicker wrote > How do you propose raising the limit for a specific test would go? > > Pragma? > Denis Kudriashov wrote >> Super!!! It's integrated (In 60201). Thank's integrators. >> >> Now we need correct default time limit and mark long tests as long. I >> opened new issue 19035 >> <https://pharo.fogbugz.com/f/cases/19035/Default-time-limit-for-tests-should-be-small> >> . >> What you think about default value? I would use 200 milliseconds. >> >> 2016-08-31 14:10 GMT+02:00 Denis Kudriashov < >> dionisiydk@ >> >: >> >>> Hi. >>> >>> I am working on SUnit improvements. I open issue 19015 >>> <https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-forked-processes-live>. >>> Slice is inbox which waits your review and feedback. >>> I was trying to address three problems: >>> >>> *1) Tests should never hang. They should be always executed within time >>> limit.* >>> >>> I give them 10 minutes for now to not change existing behaviour of >>> tests. >>> At next step it should be really reduced to ~100 milliseconds (?). >>> Any TestCase could redefine time limit by method #defaultTimeLimit. >>> Or it could be specified directly in test code by >>> self timeLimit: 10 seconds >>> (could be changed at any time of test execution). >>> >>> To implement this logic special watch dog process is running for given >>> test suite to control execution time of tests. It is single process for >>> full test suite. >>> >>> *2) When test completes all forked processes should be terminated.* >>> >>> If your tested code produced zombie processes SUnit will take care about >>> destroying all such garbage. >>> (it not means that you don't need to clean table in #tearDown but any >>> code >>> could be broken and running tests should not produce dirty system). >>> >>> *3) Any failures inside forked processes should not spawn debugger while >>> running tests.* >>> Only when we debug tests we need debugger on forked failed processes. >>> During normal run SUnit should prevent such "background debuggers" and >>> mark such tests as failed. >>> >>> To implement this behaviour SUnit will handle errors from forked >>> processes >>> by suspending them and collecting them in special collection. >>> I introduce TestFailedByForkedProcess error to signal these kind of >>> problems at the end of tests. This error is resumable and resume will >>> opens >>> debuggers of suspended failures (in fact it will resume suspended >>> processes). >>> So to debug background failures you will need extra Proceed action on >>> debugger when TestFailedByForkedProcess is signalled. >>> But in normal run such tests will be just failed by >>> TestFailedByForkedProcess error. >>> >>> *Now details on how it is done:* >>> >>> I introduce special process specific variable >>> CurrentExecutionEnvironment. >>> It is not installed by default and as default value it returns >>> DefaultExecutionEnvironment instance. >>> This variable is inheritable. If your install concrete environment into >>> process it will be installed to any child process. >>> >>> So value of variable is instance of ExecutionEnvironment subclasses and >>> you can install it by: >>> >>> anYourExecutionEnvironment beActiveDuring: aBlock >>> >>> >>> When block completes previous environment is restored. >>> For default environment there is class side method: >>> >>> DefaultExecutionEnvironment beActiveDuring: aBlock >>> >>> >>> And to reset current environment to default: >>> >>> DefaultExecutionEnvironment beActive. >>> >>> >>> SUnit introduces TestExecutionEnvironment which implements all described >>> behaviour for time limits and forked processes. >>> To activate environment there is new method #runCaseManaged. And >>> submitted >>> slice uses it instead of simple runCase. >>> >>> TestCase>>runCaseManaged >>> CurrentExecutionEnvironment runTestCase: self >>> >>> >>> DefaultExecutionEnvironment will install new TestExecutionEnvironment >>> and >>> delegate processing to it. And if TestExecutionEnvironment is already >>> active it will just process new test case. >>> >>> Now monkey has problem in checking slice (annoying timeout for loading). >>> So I can't see real system impact. But it should not stop you from >>> review >>> :)) >>> I think it is very important features for all our tests. And environment >>> idea will lead to very interesting future. >>> >>> Best regards, >>> Denis >>> -- View this message in context: http://forum.world.st/SUnit-improvements-need-review-and-feedback-tp4913413… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 3, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Paul DeBruicker

How do you propose raising the limit for a specific test would go? Pragma? Denis Kudriashov wrote > Super!!! It's integrated (In 60201). Thank's integrators. > > Now we need correct default time limit and mark long tests as long. I > opened new issue 19035 > <https://pharo.fogbugz.com/f/cases/19035/Default-time-limit-for-tests-should-be-small> > . > What you think about default value? I would use 200 milliseconds. > > 2016-08-31 14:10 GMT+02:00 Denis Kudriashov < > dionisiydk@ > >: > >> Hi. >> >> I am working on SUnit improvements. I open issue 19015 >> <https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-forked-processes-live>. >> Slice is inbox which waits your review and feedback. >> I was trying to address three problems: >> >> *1) Tests should never hang. They should be always executed within time >> limit.* >> >> I give them 10 minutes for now to not change existing behaviour of tests. >> At next step it should be really reduced to ~100 milliseconds (?). >> Any TestCase could redefine time limit by method #defaultTimeLimit. >> Or it could be specified directly in test code by >> self timeLimit: 10 seconds >> (could be changed at any time of test execution). >> >> To implement this logic special watch dog process is running for given >> test suite to control execution time of tests. It is single process for >> full test suite. >> >> *2) When test completes all forked processes should be terminated.* >> >> If your tested code produced zombie processes SUnit will take care about >> destroying all such garbage. >> (it not means that you don't need to clean table in #tearDown but any >> code >> could be broken and running tests should not produce dirty system). >> >> *3) Any failures inside forked processes should not spawn debugger while >> running tests.* >> Only when we debug tests we need debugger on forked failed processes. >> During normal run SUnit should prevent such "background debuggers" and >> mark such tests as failed. >> >> To implement this behaviour SUnit will handle errors from forked >> processes >> by suspending them and collecting them in special collection. >> I introduce TestFailedByForkedProcess error to signal these kind of >> problems at the end of tests. This error is resumable and resume will >> opens >> debuggers of suspended failures (in fact it will resume suspended >> processes). >> So to debug background failures you will need extra Proceed action on >> debugger when TestFailedByForkedProcess is signalled. >> But in normal run such tests will be just failed by >> TestFailedByForkedProcess error. >> >> *Now details on how it is done:* >> >> I introduce special process specific variable >> CurrentExecutionEnvironment. >> It is not installed by default and as default value it returns >> DefaultExecutionEnvironment instance. >> This variable is inheritable. If your install concrete environment into >> process it will be installed to any child process. >> >> So value of variable is instance of ExecutionEnvironment subclasses and >> you can install it by: >> >> anYourExecutionEnvironment beActiveDuring: aBlock >> >> >> When block completes previous environment is restored. >> For default environment there is class side method: >> >> DefaultExecutionEnvironment beActiveDuring: aBlock >> >> >> And to reset current environment to default: >> >> DefaultExecutionEnvironment beActive. >> >> >> SUnit introduces TestExecutionEnvironment which implements all described >> behaviour for time limits and forked processes. >> To activate environment there is new method #runCaseManaged. And >> submitted >> slice uses it instead of simple runCase. >> >> TestCase>>runCaseManaged >> CurrentExecutionEnvironment runTestCase: self >> >> >> DefaultExecutionEnvironment will install new TestExecutionEnvironment and >> delegate processing to it. And if TestExecutionEnvironment is already >> active it will just process new test case. >> >> Now monkey has problem in checking slice (annoying timeout for loading). >> So I can't see real system impact. But it should not stop you from review >> :)) >> I think it is very important features for all our tests. And environment >> idea will lead to very interesting future. >> >> Best regards, >> Denis >> -- View this message in context: http://forum.world.st/SUnit-improvements-need-review-and-feedback-tp4913413… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 3, 2016

Re: [Pharo-dev] Idea: User-Installed Nautilus Package Group

by Esteban Lorenzano

> On 3 Sep 2016, at 17:06, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I've often wanted to know which packages I had personally installed in an > image (i.e. non-kernel). Our one-level-deep package nesting makes the full > list unnavigable, so how about a Nautlius group where all new packages get > included automatically? We could clear it out prior to release et voila! > > What do you think? +1 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Idea-User-Installed-Nautilus-Package-Group-tp4913942.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 3, 2016

Re: [Pharo-dev] Idea: User-Installed Nautilus Package Group

by Thierry Goubier

Le 03/09/2016 Ã 17:06, Sean P. DeNigris a Ã©crit : > I've often wanted to know which packages I had personally installed in an > image (i.e. non-kernel). Our one-level-deep package nesting makes the full > list unnavigable, so how about a Nautlius group where all new packages get > included automatically? We could clear it out prior to release et voila! > > What do you think? I have a recent packages category in AltBrowser which works like that. Limited to the last ten entries, but maybe could be limitless instead. Another benefit, when you teach newcomers: - A constant, direct path in the browser to the last package created(*) or loaded in the image. 3 times out of four, students misread the package name they are supposed to create, and finding it for them in Nautilus is a pain. Thierry (*) The old system browser used to have such a constant path: last package in the list of packages. This feature is no more in Nautilus. I reintroduced it in AltBrowser. > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Idea-User-Installed-Nautilus-Package-Group-tp4913942.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 3, 2016