[Pharo-dev] streamlining creation of gtInspector extensions

Just a passing thought (that I'm sorry I don't have time to explore myself right now) ... I wonder if GT devs might experiment with streamlining discover-ability of existing and creation of new extensions by being able to right-click the tabs to get a menu * Show Definition - which opens a

Re: [Pharo-dev] About file printOn: method

+1 > Sent: Saturday, September 03, 2016 at 10:39 AM > From: stepharo > To: "Pharo Development List" > Subject: [Pharo-dev] About file printOn: method > > Hi > > > I will implement the following because this is too annoying. > > currently > >

Re: [Pharo-dev] could we discuss 19006

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

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

2016-09-03 19:11 GMT+02:00 Paul DeBruicker : > Oh wait I see in the first message in this thread you have > > self timeLimit: 10 seconds > yes

[Pharo-dev] Message browser strange new behavior

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

[Pharo-dev] pillar ast & tokens

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

[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

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

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

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

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

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

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 >

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

> On 3 Sep 2016, at 17:06, Sean P. DeNigris 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

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

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

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

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 . What you think about default value? I would use 200

[Pharo-dev] [pharo-project/pharo-core] 6935ea: 60201

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6935ea9aa84fa515949c012d529437e1319e763f https://github.com/pharo-project/pharo-core/commit/6935ea9aa84fa515949c012d529437e1319e763f Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

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

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

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!

[Pharo-dev] About file printOn: method

Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference }

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

2016-09-03 11:17 GMT+02:00 Denis Kudriashov : > > 2016-09-03 9:48 GMT+02:00 Nicolas Cellier gmail.com>: > >> For floating points it would be good to also have something related to >> unit of least precision like I think it exists in google tests:

[Pharo-dev] [pharo-project/pharo-core]

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

[Pharo-dev] [pharo-project/pharo-core] 7ba4f9: 60200

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7ba4f9c5ad6e8b0765f38d6c4baead332aee61bb https://github.com/pharo-project/pharo-core/commit/7ba4f9c5ad6e8b0765f38d6c4baead332aee61bb Author: Jenkins Build Server Date:

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

2016-09-03 9:48 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com>: > For floating points it would be good to also have something related to > unit of least precision like I think it exists in google tests: > > assert: aFloat isWithin: anInteger ulpFrom: anotherFloat > ^(aFloat -

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

2016-09-03 9:22 GMT+02:00 stepharo : > Denis > > can we also have > > assert: aNumber withPrecision: precision equals: otherNumber > > self > assert: (aNumber round: precision) > equals: otherNumber > > assert: aNumber closeTo: otherNumber > > assert:

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

Hi 2016-09-03 9:22 GMT+02:00 stepharo : > *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

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

For floating points it would be good to also have something related to unit of least precision like I think it exists in google tests: assert: aFloat isWithin: anInteger ulpFrom: anotherFloat ^(aFloat - anotherFloat) abs <= (anotherFloat ulp max: aFloat ulp) It's testing if the result are

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

Denis can we also have assert: aNumber withPrecision: precision equals: otherNumber self assert: (aNumber round: precision) equals: otherNumber assert: aNumber closeTo: otherNumber assert: aNumber withPrecision: self defaultPrecision equals: otherNumber