May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] R: [Screencast] request for review

by Laurent Laffont

Le vendredi 2 mai 2014, 09:08:49 Lorenzo Schiavina a Ã©crit : > Hi Laurent, > > if you need a help in Italian, I am available. Yes, I need help :) I don't speak Italian. Laurent > > Lorenzo > > -----Messaggio originale----- > Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di > Laurent Laffont > Inviato: giovedÃ¬ 1 maggio 2014 23:21 > A: pharo-dev(a)lists.pharo.org > Oggetto: [Pharo-dev] [Screencast] request for review > > Hi, > > I've recorded a screencast for Pharo 3.0. Could some of you review the > english subtitles ? > > Project is here: https://github.com/lolgzs/pharo-picasa-screencast , > subtitles in picasa_pharo3.en.srt. It's a simple text format, but you can > use tools like KDE subtitle composer or Jubler to edit it. You can either > send me fix by mail or make merge requests on github (easier for me :). > > > Next the idea is to have subtitles translated into several languages, help > appreciated. > > And if you have courage and time :), it would be nice to have voice recorded > (my spoken english sounds, well, ... ). > > The screencast may be published on new Pharo website for people to get > started. > > Cheers, > > Laurent >

May 2, 2014

Re: [Pharo-dev] Usage of should: in tests

by Nicolas Cellier

2014-05-02 9:46 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > 2014-05-02 0:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 01 May 2014, at 00:52, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> > Hi, >> > I see many usage of #should: in SciSmalltalk tests that could simply be >> turned into #assert: or eventually #assert:equals: >> > Why wanting to use a block? >> > Other than #should:raise: and #shouldnt:raise:, I don't really see the >> point of #should: alone anyway... >> > IMO should: should be deprecated, less is more. >> > I'm possibly the author of several of these #should: sends, so don't >> take it personnally ;) >> > >> > P.S. or is it easier to restart the block in the Debugger? >> > I cross post to pharo-dev because it's a generic question, and there >> are a few #should: sends in Pharo-3.0 too. >> >> I also do not understand why you would want to use a block. So unless >> there is a good reason to use that, a simpler API is preferable. >> >> BTW, and this was discussed before, #shouldnt:raise: is useless as well >> ;-) >> > > Yes, shouldnt: [...] raise: Error is completely useless because SUnit will > catch the Error anyway. > There are a few examples in SciSmalltalk that should be removed. > Most of the time, an Error did effectively occur, so the #shouldnt:raise: > tests were conceived as sort of explicit non regression test... > But, the tests do not have to carry these historical bits. It's obvious > that there should not be an Error raised, and the tests should rather > concentrate on testing correctness of the result. > > I don't remember if there are a few pattern for usage of shouldnt:raise:, > I was thinking for example if you want to tests an Exception handler... OK > SUnit will catch any kind of Error too, but what if it is a Notification? > > Nicolas > > Ah, here is a pattern that looks completely correct to me: testIfNil | object block | object := ProtoObject new. self shouldnt: [ object ifNil: [ self halt ]] raise: Halt. self assert: (object ifNil: [ nil ]) == object. "Now the same without inlining." block := [ self halt ]. self shouldnt: [ object ifNil: block ] raise: Halt. block := [ nil ]. self assert: (object ifNil: block) == object.

May 2, 2014

Re: [Pharo-dev] Usage of should: in tests

by Nicolas Cellier

2014-05-02 0:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 01 May 2014, at 00:52, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Hi, > > I see many usage of #should: in SciSmalltalk tests that could simply be > turned into #assert: or eventually #assert:equals: > > Why wanting to use a block? > > Other than #should:raise: and #shouldnt:raise:, I don't really see the > point of #should: alone anyway... > > IMO should: should be deprecated, less is more. > > I'm possibly the author of several of these #should: sends, so don't > take it personnally ;) > > > > P.S. or is it easier to restart the block in the Debugger? > > I cross post to pharo-dev because it's a generic question, and there are > a few #should: sends in Pharo-3.0 too. > > I also do not understand why you would want to use a block. So unless > there is a good reason to use that, a simpler API is preferable. > > BTW, and this was discussed before, #shouldnt:raise: is useless as well ;-) > Yes, shouldnt: [...] raise: Error is completely useless because SUnit will catch the Error anyway. There are a few examples in SciSmalltalk that should be removed. Most of the time, an Error did effectively occur, so the #shouldnt:raise: tests were conceived as sort of explicit non regression test... But, the tests do not have to carry these historical bits. It's obvious that there should not be an Error raised, and the tests should rather concentrate on testing correctness of the result. I don't remember if there are a few pattern for usage of shouldnt:raise:, I was thinking for example if you want to tests an Exception handler... OK SUnit will catch any kind of Error too, but what if it is a Notification? Nicolas

May 2, 2014

Re: [Pharo-dev] [ANN] Pharo3 Dark Theme is available

by Laurent Laffont

Thanks a lot, I've been waiting (and tried yes :) this for years ! Laurent Le jeudi 1 mai 2014, 13:24:15 Esteban Lorenzano a Ã©crit : > Dark Theme for Pharo 3 > ================== > > So, I finally took some time and hacked a Dark Theme for Pharo 3: > > > > How you install it? You need to execute this script: > > â1. You need this because otherwise Gofer merge becomes dumb :P" > MCRepositoryGroup default > addRepository: (MCSmalltalkhubRepository > owner: 'estebanlm' > project: 'Pharo3DarkTheme'). > â2. Now we can actually MERGE the project" > Gofer it > smalltalkhubUser: 'estebanlm' project: 'Pharo3DarkTheme'; > package: 'Pharo3DarkTheme'; > merge. > â3. And then install it" > Pharo3DarkTheme installFullTheme. > > WARNING 1: You need to do a merge (notice the script) > WARNING 2: Yes, this is a HACK (also: an ugly hack). See below for details. > WARNING 3: This changes something in the Pharo3Theme too... so you can go back after installing, but not completely :) > > Considerations > -------------- > > It can look like an easy task, to make a theme over a non native GUI like Pharo, but let me tell you: It is not. There are a lot of glitches and errors of design you have to overcome to get a working version of a theme. This is a pitty because we claim that our system is clean (or should be clean) and easy to understand. > > But all the Morphic implementation is a hack over a hack, with preconcepts and hardcodes everywhere, up to a point that to make the smallest change is an incredibly annoying task. > > Then... I added ""yet another hack"" to this infinite list. I made it because we need something like this, even if not a good solution. And I also made it to start a debate into our community. I truly believe that Morphic was a great idea, but I also believe that current implementation is doomed. I would like to discuss a new implementation, with a good design (for example I believe it should be a clear separation between a morph and it's skin, making easy the actual-hard task of changing a colorset). > I also believe there will be a clear separation between what is a Morph (a graphical unit) and a Widget (who at the time should use morphs, but that's another story). > Etc., etc., etc. > > So, will we start the longtime postponed effort of effectively replace current Morphic? > > In the mean time, enjoy the theme. Is so cool that I'm considering making it my default theme :P > > Esteban >

May 2, 2014

R: [Screencast] request for review

by Lorenzo Schiavina

Hi Laurent, if you need a help in Italian, I am available. Lorenzo -----Messaggio originale----- Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Laurent Laffont Inviato: giovedÃ¬ 1 maggio 2014 23:21 A: pharo-dev(a)lists.pharo.org Oggetto: [Pharo-dev] [Screencast] request for review Hi, I've recorded a screencast for Pharo 3.0. Could some of you review the english subtitles ? Project is here: https://github.com/lolgzs/pharo-picasa-screencast , subtitles in picasa_pharo3.en.srt. It's a simple text format, but you can use tools like KDE subtitle composer or Jubler to edit it. You can either send me fix by mail or make merge requests on github (easier for me :). Next the idea is to have subtitles translated into several languages, help appreciated. And if you have courage and time :), it would be nice to have voice recorded (my spoken english sounds, well, ... ). The screencast may be published on new Pharo website for people to get started. Cheers, Laurent

May 2, 2014

download from website: missing .sources file

by Johan Brichau

Hi guys, Really nice job on the new website. Congrats! Though this one keeps popping up over and over again: the .sources file is _not_ available for download from the website. If you download the vm and the image, you still need to get the .sources from somewhere else. It would be really good to fix that. cheers Johan

May 2, 2014

Re: [Pharo-dev] Dev Art from Google

by Alexandre Bergel

Indeed, I have a personal project exactly about thatâ¦ I hope to concretize it this yearâ¦ Alexandre On Mar 25, 2014, at 4:03 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > Moose art visualizations if not more from Phratch et als can make a mark here. > > > https://devart.withgoogle.com/?utm_source=email&utm_medium=gsp&utm_campaign… > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 2, 2014

Re: [Pharo-dev] [ANN] Pharo3 Dark Theme is available

by Alexandre Bergel

Indeed, this would be very cool Alexandre On May 1, 2014, at 4:43 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > However, I would dream of merging Roassal(2) and Morphic. Use Roassal DSLs and infrastructure to make Morphic simpler, and build fully integrated GUIs (code exploration tools, or even a system browser) where some of the widgets are Roassal(s). This was my dream when I started my browser: have a full screen representation of the code inside my image, as an interactive background to my Pharo, and editors floating there and there to edit the code, run it, explore it, debug it, etc... -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 1, 2014

Re: [Pharo-dev] [ANN] Pharo3 Dark Theme is available

by Sebastian Sastre

Oh Estebanâ¦ there is a lot of love in your heart manâ¦ This is so refreshingâ¦ And to share some more, hereâ¦ there you have guys, this is our current dev theme at flowing https://github.com/sebastianconcept/Pharo3DawnTheme sebastian o/ On May 1, 2014, at 8:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dark Theme for Pharo 3 > ================== > > So, I finally took some time and hacked a Dark Theme for Pharo 3: > > <Screen Shot 2014-05-01 at 13.11.57.png> > > How you install it? You need to execute this script: > > â1. You need this because otherwise Gofer merge becomes dumb :P" > MCRepositoryGroup default > addRepository: (MCSmalltalkhubRepository > owner: 'estebanlm' > project: 'Pharo3DarkTheme'). > â2. Now we can actually MERGE the project" > Gofer it > smalltalkhubUser: 'estebanlm' project: 'Pharo3DarkTheme'; > package: 'Pharo3DarkTheme'; > merge. > â3. And then install it" > Pharo3DarkTheme installFullTheme. > > WARNING 1: You need to do a merge (notice the script) > WARNING 2: Yes, this is a HACK (also: an ugly hack). See below for details. > WARNING 3: This changes something in the Pharo3Theme too... so you can go back after installing, but not completely :) > > Considerations > --------------

May 1, 2014

Re: [Pharo-dev] Usage of should: in tests

by Sven Van Caekenberghe

On 01 May 2014, at 00:52, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi, > I see many usage of #should: in SciSmalltalk tests that could simply be turned into #assert: or eventually #assert:equals: > Why wanting to use a block? > Other than #should:raise: and #shouldnt:raise:, I don't really see the point of #should: alone anyway... > IMO should: should be deprecated, less is more. > I'm possibly the author of several of these #should: sends, so don't take it personnally ;) > > P.S. or is it easier to restart the block in the Debugger? > I cross post to pharo-dev because it's a generic question, and there are a few #should: sends in Pharo-3.0 too. I also do not understand why you would want to use a block. So unless there is a good reason to use that, a simpler API is preferable. BTW, and this was discussed before, #shouldnt:raise: is useless as well ;-)

May 1, 2014