September 2015 - Pharo-users

Re: [Pharo-users] not yet / should be implemented

by Stephan Eggermont

On 29-09-15 12:03, Carlo wrote: > This is one of those things where everyone has their personal opinions and probably not much payoff but anyway here are my thoughts. > ShouldBeImplemented - this was supposed to be already implemented > This is a stronger form of communication where some abstract behaviour should have been implemented. If this is received in code then this should be considered an error as a base class expects derived classes to have the behaviour or the class will not work as expected. > NotYetImplemented - this will be implemented in very soon > This is a weaker form of some missing behaviour. This is used to communicate that some behaviour has not been implemented yet, and it would be nice if it was but the rest of the object is still functional. If you'd like the behaviour either harass the owner or write it yourself. Sometime this usage is abused and developers create objects that are not polymorphic and typically break Liskov's Substitution Principle for example. > So I would suggest keep the 2 as they communicate different ideas. From a lean/agile perspective, NotYetImplemented is inventory that we try to eliminate from the system. There are lots of places in Pharo where we support doing 'the right thing' by steering with our tools. The most well known is of course the browser that makes it annoying to use long methods. I'd prefer NotYetImplemented to be removed. Stephan

Sept. 29, 2015

Re: [Pharo-users] not yet / should be implemented

by Carlo

Hi This is one of those things where everyone has their personal opinions and probably not much payoff but anyway here are my thoughts. ShouldBeImplemented - this was supposed to be already implemented This is a stronger form of communication where some abstract behaviour should have been implemented. If this is received in code then this should be considered an error as a base class expects derived classes to have the behaviour or the class will not work as expected. NotYetImplemented - this will be implemented in very soon This is a weaker form of some missing behaviour. This is used to communicate that some behaviour has not been implemented yet, and it would be nice if it was but the rest of the object is still functional. If you'd like the behaviour either harass the owner or write it yourself. Sometime this usage is abused and developers create objects that are not polymorphic and typically break Liskov's Substitution Principle for example. So I would suggest keep the 2 as they communicate different ideas. Cheers Carlo On 29 Sep 2015, at 9:44 AM, stepharo <stepharo(a)free.fr> wrote: To me NotYetImplemented is not needed => should be implemented is enough Le 28/9/15 21:09, Peter UhnÃ¡k a Ã©crit : > What is the difference? > > âââââââââââââââââââââââââââââââââââââ > ShouldBeImplemented > > I am ShouldBeImplemented, an exception signaled when some method should have been implemented but was not. > > This is more like a placeholder during development. > âââââââââââââââââââââââââââââââââââââ > NotYetImplemented > > I am NotYetImplement, an exception signaled when a method is a stub for code that will be implemented in the future. > > This is used in incremental development, for example when doing Test First development. > It is similar to ShouldBeImplemented, with a slightly different meaning. > âââââââââââââââââââââââââââââââââââââ > > There seem to be some slight semantic difference but I'm failing to see it. > I can even say "The method should be implemented, but is not yet implemented." It's saying the same thing with different words. > > > Thanks, > Peter

Sept. 29, 2015

Re: [Pharo-users] not yet / should be implemented

by stepharo

To me NotYetImplemented is not needed => should be implemented is enough Le 28/9/15 21:09, Peter UhnÃ¡k a Ã©crit : > What is the difference? > > âââââââââââââââââââââââââââââââââââââ > *ShouldBeImplemented* > * > * > I am ShouldBeImplemented, an exception signaled when some method > should have been implemented but was not. > > This is more like a placeholder during development. > âââââââââââââââââââââââââââââââââââââ > *NotYetImplemented* > > I am NotYetImplement, an exception signaled when a method is a stub > for code that will be implemented in the future. > > This is used in incremental development, for example when doing Test > First development. > It is similar to ShouldBeImplemented, with a slightly different meaning. > âââââââââââââââââââââââââââââââââââââ > > There seem to be some slight semantic difference but I'm failing to > see it. > I can even say "The method should be implemented, but is not yet > implemented." It's saying the same thing with different words. > > > Thanks, > Peter

Sept. 29, 2015

Re: [Pharo-users] Pharo - database without database

by stepharo

Mariano soon with spur 64bits we will see :) Le 28/9/15 14:57, Mariano Martinez Peck a Ã©crit : > > > On Mon, Sep 28, 2015 at 7:17 AM, Stephan Eggermont <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > On 27-09-15 18:47, Adam wrote: > > 1) Object memory limit: Current object memory of Pharo is > limited to 4GB. Free > version of GemStone/S is also limited to 4GB, so I would > rather stick with > Pharo until I reach this level. And in the future this limit > grow due to 64bit > version of VM. > > > The information on GemStone seems incorrect. > https://gemtalksystems.com/licensing/ > What I read there is that the Limited (email address required) > license supports 50 GB of (on-disk) objects, with a 2GB shared > page cache. > > > On the one hand, the license has changed starting in GemStone version > 3.2. On the other hand, the "memory" limit you are talking about is > called Share Page Cache and it's more a "soft" limit in the sense that > is simply a cache of the persistent objects brought from disk. If you > have a small "cache" the performance will be bad because of trashing > (objects going and coming back from disk) but it doesn't mean the > program won't be able to run because it doesn't fit. > > Free GemStone version involves a 2GB SPC. That is normally enough for > small/medium apps. > > That is completely different as the "memory" limit for Pharo. > > > > -- > Mariano > http://marianopeck.wordpress.com

Sept. 29, 2015

Re: [Pharo-users] Question about color

by Alejandro Infante

As far as I remember, Color>>#r:g:b: expects 3 numbers between 0 and 1, instead of integers from 0 to 255. Inspecting a color using the fractions proposed by Wolframalpha gives you the expected color: Color r: 0.06 g: 0.39 b: 0.39 Cheers, Alejandro > On Sep 28, 2015, at 11:07 PM, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > > Hi, > > At a local workshop we're working with the Pharo tutorial and we use the classical example of RGB colors for keyword messages. When we use the Prof Stef's example we get the following screenshot: > > <djjjjajg..png> > > While executing the same color in Wolfram Alpha gives us: > > <dgcdicbd..png> > > As you can see, both colors are pretty different. Which is the reason behind the differences in the color that is shown in Pharo and the one in WA? > > Cheers, > > Offray

Sept. 29, 2015

Question about color

by Offray Vladimir Luna CÃ¡rdenas

Hi, At a local workshop we're working with the Pharo tutorial and we use the classical example of RGB colors for keyword messages. When we use the Prof Stef's example we get the following screenshot: While executing the same color in Wolfram Alpha gives us: As you can see, both colors are pretty different. Which is the reason behind the differences in the color that is shown in Pharo and the one in WA? Cheers, Offray

Sept. 29, 2015

Re: [Pharo-users] Some news from the growing pharo teacher front

by Offray Vladimir Luna CÃ¡rdenas

Hi Stephan, and welcome John, In the same line of teaching with Pharo, the last week we had our second edition of the data week, an intensive workshop on data visualization using pharo. This was a pretty small group, of max 6 people, but is nice to see how pharo can serve well different communities and approaches of learning. We updated our Grafoscopio tutorial and now includes the adaptation of prof stef and now we're creating our first lessons on data scrapping. Here is a screenshot, and at [1] you can get the last version, to open it as a grafoscopio interactive document. [1] http://mutabit.com/repos.fossil/grafoscopio/finfo?name=Docs/Es/Tutoriales/t… Cheers, Offray On 26/09/15 09:05, ATTIOGBE Damessi Douwonou wrote: > Hello Stephane and All, > > I'm John student from TOGO! I'm verry happy to meet PHARO on my road :) > > I will do my best to be Pharo master. > > i like Pharo! > > 2015-09-26 11:31 GMT+00:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > I want to let you know that there will be a new pharo lecture in > YaoundÃ©. I presented Pharo during a seminar and the > previous minister of education was there and asked us to do a > lecture. In June we did it with Damien C. by skype. > And now there is an official lecture at YaoundÃ© given by Prof. > Metalagia. This is an excellent news. I will give some lectures in > december there. > > In Togo my first visit was quite successful: 120 participants to > the conferences I gave (it was still vacation time there). > There were 60 students following lectures from 8h to 17h during 4 > days... Yes I'm exhausted ;) > A new Pharo lecture will start in north Togo. I will go back in > December. > > One of the idea is to help students to get good in Pharo and pharo > web stack and build web apps and other. > I hope that we can have within 2/3 year > There is a competition AppTogo. People are learning C# and others. > I hope that some students will compete with Pharo so I will be > looking for potential mentors to help them. > Giving them advices, pointing them to the right solution/framework > and may be a bit of pair rogramming if skype > works. > > I distributed the Pharo Starter Kit (we will announce it > officially now that I have 10 gb space on my server) > People love the Youtube videos folder I'm collecting. Yes internet > is a pain there. > Chloupis I put your great youtube tutorial! Thanks for it. some > students watched it. > > Stef > > > > > -- > *John ATTIOGBE.* >

Sept. 29, 2015

Re: [Pharo-users] Pharo - database without database

by Dale Henrichs

Adam, Keep an eye on the GLASS list[1] for an upcoming (within 2 months - I promise:) announcement about GsDevKit_home (not to be confused with gsDevKitHome:)... as it will provide much needed support for creating/starting/managing multiple GemStone stones.... If you are interested in working with GemStone:) Dale [1] http://forum.world.st/GLASS-f1460844.html On 09/28/2015 12:48 PM, Adam wrote: > Hello, > > Yes, I was confused by some old discussion. New licence is different. Thanks > for correction. > > Adam. > > Dne Po 28. zÃ¡ÅÃ 2015 12:17:19, Stephan Eggermont napsal(a): >> On 27-09-15 18:47, Adam wrote: >>> 1) Object memory limit: Current object memory of Pharo is limited to 4GB. >>> Free version of GemStone/S is also limited to 4GB, so I would rather >>> stick with Pharo until I reach this level. And in the future this limit >>> grow due to 64bit version of VM. >> The information on GemStone seems incorrect. >> https://gemtalksystems.com/licensing/ >> What I read there is that the Limited (email address required) license >> supports 50 GB of (on-disk) objects, with a 2GB shared page cache. >> >> Stephan

Sept. 28, 2015

Re: [Pharo-users] A keyboard controlled code editor, how difficult would that be?

by Peter UhnÃ¡k

As for changing/updating the code in the cards... maybe we can look at MessageBrowser because it should have all the necessary behavior. Peter On Mon, Sep 28, 2015 at 4:58 PM, Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Thanks Peter, seems a problem related with thunderbird. I will see what's > happening. Cheers, > > Offray > > > On 28/09/15 09:55, Peter UhnÃ¡k wrote: > > On Mon, Sep 28, 2015 at 4:25 PM, Offray Vladimir Luna CÃ¡rdenas < > <offray(a)riseup.net>offray(a)riseup.net> wrote: > >> Peter, Could you share a link to a bigger screenshot of your workflow >> with code cards? Just curious about this feature. >> > > Hmm, what email client are you using? Because the image was not resized. > > world.st shows the image downscaled > http://forum.world.st/A-keyboard-controlled-code-editor-how-difficult-would… > but if you right-click and "open image in new tab" it is in original size, > > the same for the actual record in the mailing list > <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-September…> > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-September… > at the end of the email there are links to attachments > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20… > > And finally gmail shows the image also downscaled, but I can simply click > on it to show it enlarged. > > So if you see the image small, blame your mail client. :) (and click the > link above) > > Peter > > >

Sept. 28, 2015

TestAsserter>>assertCollection:hasSameElements:

by Peter UhnÃ¡k

How practical it is to do set-based comparison in TestAsserter>>assertCollection:hasSameElements: ? For example #(1 1 2) has same elements as #(1 2) which may make sense for sets, but not for bags. The main reason I was using it is that in tests the expected collection may be created by hand, which means it is very often an array #(...), { ... }, while models very often return OrderedCollections (at least in my case). So my question is --- how to compare collections irrespective of type, and possibly of order? A) always convert the actual collection toanArray B) change difference: behavior for non-sets (ton of work with catastrophic consequences) C) extend TAssertable with new methods like #assertElementsOf: actualCollection equals: expectedCollection #assertUnorderedElementsOf: actualCollection equals: expectedCollection C.a) directly in Pharo/SUnit C.b) in independend SUnit-Extensions repository/project C.c) just in my project D) stop discussing non-problems Thanks, Peter

Sept. 28, 2015