[Pharo-dev] [pharo-project/pharo-core] e64121: 60202

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

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

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

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

And it is worth breaking all the book chapters and videos. I think that assert: closeTo: kind of solution is - simple - regular with the other assert: - incremental So maximum quality. Stef

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

Nicolas I like your ideas can you propose (code) something? Stef Le 3/9/16 à 09:48, Nicolas Cellier a écrit : 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:

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

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

It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +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

Re: [Pharo-dev] Message browser strange new behavior

Hi denis I looked at senders of iconNamed: and when I see a Smalltalk ui icons iconNamed: I change it into self iconNamed: when I can. May be I was also changing the superclass to be Model and this would be the problem. It would be nice to have the possibility to get the list displayed

[Pharo-dev] about package naming

Hi guys Sorry to be that dull and stupid but I do not get why (beside following the seaside convention - and I do not understand it either) why the test package for FileSystem-Core is named FileSystem-Tests-Core and not just FileSystem-Core-Tests like that we could have

[Pharo-dev] Please review: FIleSystem displayString and printOn: to support better tweaking in playground and friends

Hi I did a first cut for FIleSystem displayString and printOn: to support better tweaking in playground and friends But I do not know if I'm happy. https://pharo.fogbugz.com/f/cases/18956/FileReference-printString-should-be-auto-evaluable Stef

Re: [Pharo-dev] could we discuss 19006

thanks. I had problems to see the code when merging. I will integrate it today if the system lets me doing it :). Le 4/9/16 à 02:19, monty a écrit : It doesn't add any new streams or other classes besides a test case. AbstractBinaryStream was already there. It just adds #sync to the

[Pharo-dev] [pharo-project/pharo-core] de28c5: 60203

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

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

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

Re: [Pharo-dev] Message browser strange new behavior

I can't reproduce (or I not see it) Could you explain more? 2016-09-03 22:11 GMT+02:00 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

[Pharo-dev] GTInspector Inspecting a string should provide default interaction shortcut

Hi when I inspect a string, the default shortcuts should be present. Stef

[Pharo-dev] OCCompilerASTPlugin

I have one question about Opal Compiler. I would like do an AST transformation before using the compiler. If I understand correctly, I have to built a subclass of OCCompilerASTPlugin ? Is it correct ? Any documentation more update about Opal than this :

[Pharo-dev] Iceberg Question

Hi! I have a question regarding the window: Why if I want to retrieve the new versions, I need to press the button “Fetch new versions”. I think I should do a pull ? But instead, i can do a load or a merge. A bit cryptic… Cheers, Alexandre --

Re: [Pharo-dev] Please review: FIleSystem displayString and printOn: to support better tweaking in playground and friends

stepharo wrote > I did a first cut for FIleSystem displayString and printOn: to support > better tweaking in playground and friends IIUC #displayString, #storeString, et al. are well-known distinctions from other platforms, correct? Are we following the convention? Also, not to digress, but

Re: [Pharo-dev] streamlining creation of gtInspector extensions

Ben Coman wrote > * Show Definition - which opens a browser on the right code > * Create Custom Extension - which opens a dialog to create a new > package "MyGTExtensions" and/or select an existing package, specify an > identifier and choose a template that is created and Browser opened. Great

Re: [Pharo-dev] about package naming

Le 04/09/2016 à 20:52, Tudor Girba a écrit : > Hi, > > That naming convention is due to the fact that there was a time when > Monticello committed the content of packages based on prefix matching. > > So, if you had: > FileSystem-Core > FileSystem-Core-Tests > committing

Re: [Pharo-dev] streamlining creation of gtInspector extensions

On Sun, Sep 04, 2016 at 11:10:26AM -0700, Sean P. DeNigris wrote: > Ben Coman wrote Do you really want to add extra hidden (because nobody would click on a tab, because nowhere else in the system it's like that) buttons just to save two seconds? > > * Show Definition - which opens a browser

Re: [Pharo-dev] about package naming

> On 04 Sep 2016, at 20:52, Tudor Girba wrote: > > Actually, we still have the bug that if you would change something in > FileSystem-Core, FileSystem-Core-Tests would be marked as dirty. I think that this happens because we pretend to have packages, but behind the

[Pharo-dev] [pharo-project/pharo-core] e14f4a: 60204

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

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

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

[Pharo-dev] Bug with Iceberg

Hi! I bumped into the following bug, which stems from the following method: -=-=-=-=-=-=-=-=-= IceSavedPackageVersion >> isAncestorOf: anotherVersion ^ self commit isAncestorOf: anotherVersion commit -=-=-=-=-=-=-=-=-= anotherVersion is nil I attached the log Cheers, Alexandre --

Re: [Pharo-dev] about package naming

Hi, That naming convention is due to the fact that there was a time when Monticello committed the content of packages based on prefix matching. So, if you had: FileSystem-Core FileSystem-Core-Tests committing FileSyste-Core would also commit FileSystem-Core-Tests as a

Re: [Pharo-dev] streamlining creation of gtInspector extensions

Peter Uhnak wrote > Well you learn it like a lot of other stuff in Pharo… by looking at code > examples, which in this case means the implementation itself. Agreed. The problem here and in other tools (as opposed to scripts) is how you get from the UI to the implementation. You're still assuming

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

EstebanLM wrote > +1 I will not open an issue because I don't have time to work on it right now and suspect it will languish and be closed (not complaining), so I will add it way down on my personal todo list and I leave opening an issue to anyone actually willing to do the work. - Cheers,

Re: [Pharo-dev] GTInspector Inspecting a string should provide default interaction shortcut

Hi, We already agreed several times that this is a bug :). I now created an issue to make sure we do not forget it: https://pharo.fogbugz.com/f/cases/19037/String-presentation-in-GTInspector-should-provide-code-actions Doru > On Sep 4, 2016, at 8:00 PM, Sean P. DeNigris

Re: [Pharo-dev] Bizarre Text Selection in Pharo 5.0

Max Leske wrote > Please open a new issue (you can add me to the notification list). Done. Sorry for the delay. https://pharo.fogbugz.com/f/cases/19036/Bizarre-Text-Selection-in-Pharo-5-0 - Cheers, Sean -- View this message in context:

Re: [Pharo-dev] GTInspector Inspecting a string should provide default interaction shortcut

stepharo wrote > when I inspect a string, the default shortcuts should be present. Yes! No modes!!! It is confusing and does not seem to fit the spirit of our system. Who can predict where a user will want/need to evaluate? I often perform doIts in the MC Browser windows, commit log dialogs, etc.

Re: [Pharo-dev] [pharo-project/pharo-core] e64121: 60202

GitHub wrote > 19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons > https://pharo.fogbugz.com/f/cases/19001 This one surprised me. I thought we were trying to avoid extensions to low-level classes when possible. How is icon retrieval a responsibility of

Re: [Pharo-dev] could we discuss 19006

stepharo wrote > Note that I'm not against. I just want to understand. Me too. I looked over the issue, and it seemed one would already have to understand the issue very well. I wished there was more explanation about the problem and why the solution was a good one. In the end, I shrugged my

Re: [Pharo-dev] about package naming

Hi, I like the FileSystem-Core-Tests more, because then we can also have FileSystem-Core-Rules and FileSystem-Core-Rules-Tests. But I think that the other way to think about this is that if you want to (un)load all the test from filesystem you just work with FileSystem-Tests and not do it

[Pharo-dev] Can Sound depend on Jobs?

I wanted to add as an extension method to the Sound package: Job>>#beepAtEnd "Sound must first be enabled via `SoundSystem soundEnabled: true.`" self announcer when: JobEnd do: [ SoundSystem current beep ] I figured I'd get some feedback first since I know we're trying to

Re: [Pharo-dev] Please review: FIleSystem displayString and printOn: to support better tweaking in playground and friends

Hi, > On Sep 4, 2016, at 7:57 PM, Sean P. DeNigris wrote: > > stepharo wrote >> I did a first cut for FIleSystem displayString and printOn: to support >> better tweaking in playground and friends > > IIUC #displayString, #storeString, et al. are well-known distinctions

Re: [Pharo-dev] streamlining creation of gtInspector extensions

Peter Uhnak wrote > Do you really want to... just to save two seconds? Of course not! Peter Uhnak wrote > that's my experience after writing 20 or 30 extensions And there's the source of the misunderstanding. Notice the key word in the original request was /discoverability/ i.e. for

Re: [Pharo-dev] streamlining creation of gtInspector extensions

On Sun, Sep 04, 2016 at 12:30:29PM -0700, Sean P. DeNigris wrote: > Peter Uhnak wrote > > Do you really want to... just to save two seconds? > > Of course not! > > > Peter Uhnak wrote > > that's my experience after writing 20 or 30 extensions > > And there's the source of the misunderstanding.

[Pharo-dev] Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

MessageNotUnderstood: Context>>messageName Is this a known bug? Should I open an issue? - Cheers, Sean -- View this message in context: http://forum.world.st/Error-When-Accepting-Changes-in-Debugger-Moose-6-on-Pharo-5-tp4914109.html Sent from the Pharo Smalltalk Developers mailing list

Re: [Pharo-dev] streamlining creation of gtInspector extensions

On Mon, Sep 5, 2016 at 3:24 AM, Peter Uhnak wrote: > On Sun, Sep 04, 2016 at 11:10:26AM -0700, Sean P. DeNigris wrote: >> Ben Coman wrote > > Do you really want to add extra hidden > (because nobody would click on a tab, because nowhere else in the system it's > like that)

Re: [Pharo-dev] Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

Doesn't look familiar. Do you have a way to reproduce it? Cheers, Andrei On Sun, Sep 4, 2016 at 11:16 PM, Sean P. DeNigris wrote: > MessageNotUnderstood: Context>>messageName > > Is this a known bug? Should I open an issue? > > > > - > Cheers, > Sean > -- > View this

Re: [Pharo-dev] Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

Andrei Chis wrote > Do you have a way to reproduce it? Not sure. I'll report back if it happens again;;; - Cheers, Sean -- View this message in context: http://forum.world.st/Error-When-Accepting-Changes-in-Debugger-Moose-6-on-Pharo-5-tp4914109p4914116.html Sent from the Pharo Smalltalk