- Pharo-users - lists.pharo.org

Re: [Pharo-users] min:max:

by Peter UhnÃ¡k

> > #beBetween:and: +1. Goes nicely with `(x beBetween: y and: z) between: y and: z` being always true. Peter On Sat, Apr 21, 2018 at 11:56 AM, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Looking at senders of #min:max:, I found in BitBlt>>roundNumbers the > following: > > > > destX := destX asInteger > > min: maxVal > > max: minVal. > > > > Which seems to summarize the illogicality very well. > > > > However, note that PetitParser, PetitParser2 and Magritte all implement > #min:max: as a method to set upper and lower limits, and there the meaning > is the logical one. It all looks a mess. > > > > Peter Kenny > > > > > > *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *On Behalf Of *Ben > Coman > *Sent:* 21 April 2018 02:16 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org>; > The general-purpose Squeak developers list <squeak-dev@lists. > squeakfoundation.org> > *Subject:* Re: [Pharo-users] min:max: > > > > > > > > On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > Out of curiosity. > > I always found the #min:max: confusing and lost in its expressiveness. > > One should write: > > 10 min: 48 max: 12 > > to expect 12. > > but logically one (at least me) may want to express it as: > > 10 min: 12 max: 48 > > Then when reading its source code, it is even more confusing: > > min: aMin max: aMax > ^ (self min: aMin) max: aMax > > Are not the argument names inversed in their meaning, if any? > > > > I would agree. I see most use by Color like... > > > > Color>>adjustBrightness: brightness > > "Adjust the relative brightness of this color. (lowest value is > 0.005 so that hue information is not lost)" > > > > ^ self class > > h: self hue > > s: self saturation > > v: (self brightness + brightness min: 1.0 max: 0.005) > > alpha: self alpha > > > > Trying to read that twists my brain. > > > > > > I can understand the intent from the implementation > > min: aMin max: aMax > > ^ (self min: aMin) max: aMax > > > > but that message might more properly be #min:thenMax: > > However something like > > (self brightness + brightness boundedBy: 0.005 and: 1.0) > > (self brightness + brightness boundedMin: 0.005 max: 1.0) > > seems more intention revealing. > > > > > > Altering #min:max semantics would make awful portability, > > but perhaps it should forward to a new method to make it clear the other > is preferred. > > > > Would the Squeak community be amenable to a similar change? > > I'd be happy to contribute the changes to the Squeak Inbox. > > > > cheers -ben >

April 21, 2018

Re: [Pharo-users] Time limit to execute a test

by Hilaire

Ah yes, it does it. Thanks Le 21/04/2018 Ã 11:58, Cyril Ferlicot a Ã©critÂ : > I don't have a computer to check but inside the test you should be > able to call a method as #timeLimit:. I'm not sure of the name. > -- Dr. Geo http://drgeo.eu

April 21, 2018

Re: [Pharo-users] Time limit to execute a test

by Cyril Ferlicot

On sam. 21 avr. 2018 at 11:55, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I have a test taking more than the 10 seconds limit to execute completely. > > I tried to adjust this limit but failed to get it taken in > consideration. I tried from 3 places: > > - in the test method itself > > - in TestCase setUp > > - in a dedicated TestResources > > The adjustment seems to alway been too late, the limit is still at 10s. > > To adjust the limit I did as following, for example in a dedicated > TestResource: > > setUp > "Some recursive scripts need more time to execute completely" > defaultTimeLimitBackup := TestCase defaultTimeLimit. > TestCase defaultTimeLimit: 60 seconds. > > tearDown > TestCase defaultTimeLimit: defaultTimeLimitBackup > > From the debugger raised at the test fail, I can see the > DefaultTimeLimit is correctly set to 60s. > > If I adjust this time limit before executing test case, for example from > the settings browser, it is going fine. But I will prefer adjust it > programmatically. > > Any idea? > Hi, I don't have a computer to check but inside the test you should be able to call a method as #timeLimit:. I'm not sure of the name. Also, if you want to raise the time limit of all the tests of the class, you don't need to call #defaultTimeLimit: but you need to override #defaultTimeLimit. > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr

April 21, 2018

Re: [Pharo-users] min:max:

by PBKResearch

Looking at senders of #min:max:, I found in BitBlt>>roundNumbers the following: destX := destX asInteger min: maxVal max: minVal. Which seems to summarize the illogicality very well. However, note that PetitParser, PetitParser2 and Magritte all implement #min:max: as a method to set upper and lower limits, and there the meaning is the logical one. It all looks a mess. Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Ben Coman Sent: 21 April 2018 02:16 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>; The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Pharo-users] min:max: On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu> > wrote: Hi, Out of curiosity. I always found the #min:max: confusing and lost in its expressiveness. One should write: 10 min: 48 max: 12 to expect 12. but logically one (at least me) may want to express it as: 10 min: 12 max: 48 Then when reading its source code, it is even more confusing: min: aMin max: aMax ^ (self min: aMin) max: aMax Are not the argument names inversed in their meaning, if any? I would agree. I see most use by Color like... Color>>adjustBrightness: brightness "Adjust the relative brightness of this color. (lowest value is 0.005 so that hue information is not lost)" ^ self class h: self hue s: self saturation v: (self brightness + brightness min: 1.0 max: 0.005) alpha: self alpha Trying to read that twists my brain. I can understand the intent from the implementation min: aMin max: aMax ^ (self min: aMin) max: aMax but that message might more properly be #min:thenMax: However something like (self brightness + brightness boundedBy: 0.005 and: 1.0) (self brightness + brightness boundedMin: 0.005 max: 1.0) seems more intention revealing. Altering #min:max semantics would make awful portability, but perhaps it should forward to a new method to make it clear the other is preferred. Would the Squeak community be amenable to a similar change? I'd be happy to contribute the changes to the Squeak Inbox. cheers -ben

April 21, 2018

Time limit to execute a test

by Hilaire

Hi, I have a test taking more than the 10 seconds limit to execute completely. I tried to adjust this limit but failed to get it taken in consideration. I tried from 3 places: - in the test method itself - in TestCase setUp - in a dedicated TestResources The adjustment seems to alway been too late, the limit is still at 10s. To adjust the limit I did as following, for example in a dedicated TestResource: setUp Â Â Â "Some recursive scripts need more time to execute completely" Â Â Â defaultTimeLimitBackup := TestCase defaultTimeLimit. Â Â Â TestCase defaultTimeLimit: 60 seconds. tearDown Â Â Â TestCase defaultTimeLimit: defaultTimeLimitBackup From the debugger raised at the test fail, I can see the DefaultTimeLimit is correctly set to 60s. If I adjust this time limit before executing test case, for example from the settings browser, it is going fine. But I will prefer adjust it programmatically. Any idea? Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 21, 2018

Re: [Pharo-users] Where do we go now ?

by Peter UhnÃ¡k

How a project is named is a choice of the author. Nobody gets to demand how someone should name their projects. Now how project is actually named is not a issue if it is properly handled on pharo side, which in some places is, in some places isn't. For instance, there's a gazillion UI frameworks out there and, most of the > time, the name used for them is one of a famous painter. We have Magritte, which is a meta-data description framework, not UI framework. :) How many Pharo *users* (not regular contributors!) know what those > tools/frameworks/packages do ??? Probably not many, because they never encounter them, nor care about whether they exist or not. A very quick look at what's in Pharo 7 shows the following names : Iceberg, > Ombu, Calypso, Flashback, Nautilus, Renraku, Zodiac, Shift, Zinc, Hermes, > Beacon, Cargo, Hermes, Opal, Shoreline, Epicea, Balloon, BlueInk, > Commander, Fuel, Glamorous, Glamour, Gofer, Hiedra, Metacello, Moose, Ring, > Rubric, Shout, Spec, etc... Calypso + Nautilus: as a user you don't get to encounter the names, there's only "System Browser" Did you know that there are other code browsers you can install? (e.g. Code Panels, Alt Browser, ...) Iceberg: as someone pointed out, this would be nice to have a "(Git) Versionner" or whatever entry instead Metacello: npm => "Package manager 1", pip => "Package manager 2", ... Ombu/Epicea: you access it via "Code Changes", names are hidden from the user Flashback, Renraku, Hermes, Opal, Shoreline, BlueInk, Hiedra, Ring, Rubric, Shout, Glamorous, Glamour: not something a regular user ever encounters directly, and if they need to, the unique name helps a lot in finding information/docs about it Moose: are you serious? should Pharo be called "Programming Language 28301" too? Commander: Commander is a library to implement commands. You literally cannot have a more descriptive name and yet you still complain. Spec: ... maybe we can rename * Morphic "UI 1" * Baloon "UI -1" * Spec "UI 2" * Rubric "UI 3" * Tx "UI A" * Bloc "UI ×" * Athens "UI Îµ" * Cairo "UI Ð©" * Sparta "UI ã" and then try to find any information about anything. Was it really that hard to replace the old workspace with Workspace2 or > WhateverWorkspace ? Or even better : get rid of the old Workspace and > replace it with Playground while retaining the name "Workspace" ??? Well I could claim that "Workspace" is a very confusing name, because it is not actually workspace, just a trivial Text Box. If anything, Playground is a much more fitting name. Or somethings as simple as Regex, the regex package from Bykov. Which variant of regular expressions though? Unless we *clearly* publicize/describe what those names are, there's no way > in a thousand years you could tell that BlueInk is not a package dealing > with fonts (that was my first guess) ! I fully agree with this, and as I've mentioned (here, or maybe in another thread), this has improved greatly with move to GitHub, as people finally started to care about describing their projects. But the transition takes time. Btw BlueInk is a "pretty printer", so the name isn't really misleading once you know what it is. But being "clever" with names is sure way to get it misinterpreted. (E.g. "grafoscopio" which has nothing to do with graphs or visualizations, as it is text/nodes/code snippets organization tool.) (For the record I tend to name projects with the most boring name I can come up with (tonel-migration, IconFactory, file-dialog, xml-magritte-generator, uml-xmi, ...), but it only works if there's only one such thing... if there are competing projects, than sharing the name doesn't help anyone.) Peter On Sat, Apr 21, 2018 at 1:34 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, Apr 20, 2018 at 07:08:29AM -0700, Sean P. DeNigris wrote: > > Stephane Ducasse-3 wrote > > > I like when developers are talking about names: > > > They use a mac and not a computer, they were nike, lewis and not shoes > > > and pants.... > > > So guys can we focus our energy on positive things. > > > > IHMO this is certainly a positive subject because it highlights the > > as-yet-to-be-resolved tension regarding understandability of the system > > between having a unique name (good for googling, distinguishing between > > versions) and a name that reveals what the project does/is for. What is > the > > plan to resolve this because it is a real problem? > > > > Nike and Levis are designed to stand on their own in front of the > consumer > > market. Is this true of Nautilus, Calypso, or Epicea? > > Sean, > > Thank you for this clarification! I read Stef's message this morning > and I honestly thought that my name ("lewis") might have something to > do with pants. That probably would not be a good thing. But now I see > that we are talking about "levis" so I feel much better now :-) > > Dave (Lewis, not Levis) > > >

April 21, 2018

Re: [Pharo-users] Projects using Magritte meta models

by Stephane Ducasse

Cool I will have a look when I go back to Magritte Rafael if you see mistake in the booklet please report them to me. I will do a pass in a couple of weeks I hope On Sat, Apr 21, 2018 at 4:07 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Rafael Luque wrote >> I wonder if there are other relevant projects I could study to discover >> other possible >> uses cases of Magritte. > > I use it in nearly all my personal projects, almost always via Morphic, not > Seaside. Here is a public one you can have a look at: > https://github.com/seandenigris/Small-World > > Load in Pharo 6.1 via: > Metacello new > baseline: 'SmallWorld'; > repository: 'github://seandenigris/SmallWorld:master/repository'; > onConflict: [ :ex | ex allow ]; > load. > > Browse senders of magritteDescription for classes prefixed with "Small". > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Stephane Ducasse

I think so On Sat, Apr 21, 2018 at 10:34 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > To use Smalltalk sketch scripts for additional unit tests, I need to file in > these script files. > > I found FileStream>>fileIn: does the job. Is it the proper way to do it? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

April 21, 2018

Proper way to file in code

by Hilaire

Hi, To use Smalltalk sketch scripts for additional unit tests, I need to file in these script files. I found FileStream>>fileIn: does the job. Is it the proper way to do it? Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 21, 2018

Migrating Seaside book to Pillar on github

by Stephane Ducasse

Hi I decided to start to migrate the Seaside book to Pillar and make it a community-oriented book. I will work regularly on it and offer it as a gift to the community. https://github.com/SquareBracketAssociates/DynamicWebDevelopmentWithSeaside If some of you want to join the effort, you are welcome. Stef

April 21, 2018