- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] For future version of Spotter

by Tudor Girba

Hi, This is on the todo list, but I would rather want to have that in settings with a button. I did not check if this is possible yet. Does anyone know if it is? Cheers, Doru > On Mar 6, 2016, at 10:53 AM, stepharo <stepharo(a)free.fr> wrote: > > Add a menu doing > > GTSpotter cleanUp. > GTSpotter dontShowPreview > > Stef > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

March 6, 2016

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

by Volkert

+100 On 06.03.2016 09:48, stepharo wrote: > Why Pharo is not smalltalk and will not be Smalltalk > > - First because we make it to free us from the past. > > - In the future we want that people that learned smalltalk in the > 90 do not discard Pharo because > > - "what killed smalltalk was that we could not work > well in team" > - "smalltalk oh it does not scale" > - "I cannot edit my code with emacs" > - "oh back in 1993 I got lecture and the system took > 10 min to boot on our sparc (I got this story yesterday)" > - I did not get how you work in team > - "with Smalltalk you cannot save your code in svn" > - "Smalltalk is monolithic" > - "you are in a cage you cannot interact with the > outside world" a guy organising OOPSLA > - "Smalltalk what a dated name! bavardage: tu > programmes en bavardage, donc les resultats ne doivent pas > etre si super que cela...." > > I do not care that these statements are right or wrong. > I do not care that people are ignorant. And yes with some education we > can show that they are wrong. > There are in the mind of people that got in touch with Smalltalk. > No more no less. > > So may be Smalltalkers should read book about marketing in general. > > So you are stuck in your history and I'm dreaming about the future: > and the future is Pharo not Smalltalk. Face it. > There will be no renewal of Smalltalk. Pharo is the chance for > Smalltalk to exist in 2050. > The future is much more important that the history. > > You do not make people dreaming telling them that back in the 1940 you > add to cross the street to fetch water. > > > > >> left blank on purpose >> >> >> >> Le 5/3/16 18:22, Eliot Miranda a Ã©crit : >>> Stef, >>> >>> On Mar 5, 2016, at 12:10 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> You probably leave in a protected environment but I do not live in >>>> the same. >>>> Did you check numPy recently or R? momemtum? >>>> Do you think that people do not know how to count? >>>> In 1980 my students were not even born, so how can it be better than >>>> python, java, c#, lua, ... >>>> >>>> Do you think that it makes me happy to see my old friends leaving >>>> our language and do node.js. >>>> Seriously. >>>> Why do you blame me? Frankly tell to leave Pharo and I will leave. >>>> I can tell you. >>>> I think that I need a break in my life in this moment so it would >>>> be a good opportunity. >>>> Because if each time I do something to improve the wealth and >>>> visibility of our system >>>> I get such kind of feedback then may be this is the time to do >>>> something. >>>> Afterall I may be wrong. >>>> Seriously if you think that I'm not doing a good job and you want >>>> to stay with old friends >>>> just let me know. but if I stay then do not tell me that I'm an >>>> asshole that does not want to >>>> promote smalltalk. >>> >>> I do not blame you. I am offended by Pharo disavowing the Smalltalk >>> name. I am offended when people state Pharo is not Smalltalk. I >>> want to refute false assumptions about the name Smalltalk, such as >>> the equating it with cobol. Instead of taking it personally why >>> don't you address my points about older programming languages whose >>> names (AFAICT) are not perceived negatively? >>> >>> >>> I support this community and am excited to participate in it. I >>> admire and respect your efforts, StÃ©phane, in developing, organizing >>> and supporting this community. But that does not mean I will keep >>> quiet about something I profoundly disagree with and think is wrong. >>> And that thing is to deny Pharo is Smalltalk. >>> >>> And I do this not because I am a zealot, but because words meaning >>> are important, because to understand each other we should call a >>> spade a spade, and because I am grateful for and delighted by this >>> thing called Smalltalk, and I will not support taking credit away >>> from it. Ruby is inspired by Smalltalk. Pharo is the real thing. >>> >>>> Stef >>>> >>>> Le 5/3/16 02:18, Eliot Miranda a Ã©crit : >>>>> >>>>> >>>>> On Fri, Mar 4, 2016 at 12:08 PM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> >>>>>> SciPharo? Not so great news from my POV. >>>>>> What is so much pharo specific in this library? >>>>>> Is Smalltalk scientific community large enough for yet >>>>>> another split? >>>>> Split of what? Let us be tagged with a name of 1980 and die in >>>>> peace. Yes this looks like a >>>>> smart move. >>>>> There are just Python and R and Javascript around (not talking >>>>> about ruby and swift) >>>>> so this is a great move. We are not the cobol of >>>>> object-oriented programming!! >>>>> >>>>> >>>>> When I read sentiments like this it makes me want to leave the >>>>> community. I find it so offensive that the Pharo community uses >>>>> Smalltalk but wants to distance itself. It feels like theft or >>>>> massive disrespect for the inventors of the language, or a >>>>> complete lack of gratitude. >>>>> >>>>> C is older than Smalltalk and no one says "C is the cobol of >>>>> low-level imperative languages". List is much older than C but no >>>>> one wants to rename Lisp because it is perceived as old. >>>>> >>>>> Smalltalk is a beautiful name, carefully chosen to differentiate >>>>> and identify the system as different, not arrogant, not >>>>> hieroglyphic. Further, Smalltalkl /is/ different and distinctive >>>>> materially. Why anyone would be ashamed of that incredible >>>>> heritage and pervasive influence is beyond me. >>>>> >>>>> Offended, >>>>> Eliot >>>> >> >

March 6, 2016

Spotter and parent file directory

by stepharo

Hi Doru/Andrei I just produced a video on using spotter for files/dir navigation. Cool Here is my feedback - why don't we get dir when we request files? - I tried ./../ #files :) Would be nice to have it - I'm spoiled with Spotter I tried to navigate a mcz file :) any taker to get the contents of the file displayed Stef

March 6, 2016

Re: [Pharo-dev] [Bloc] about resizing

by stepharo

Oki I will :) Le 6/3/16 11:13, Aliaksei Syrel a Ã©crit : > > Now it is clear and makes sense. Yes, it should be renamed! > > On Mar 6, 2016 11:10 AM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Wait you confuse me. > > My only point is > > - Class should not end in ing but in er > DeepCopier is not DeepCopying > PragmaCollector is not PragmaCollecting > > - So if I set (using a setter) an attribute to an object passing a > resizer the name of the setter should not be resizing: > (BlLayoutExactResizer new) > > I could understand if this is a general method but the selector is > not really nice either > I would prefer in that case resizeWith: (BlLayoutExactResizer new) > > Am'I clear? > Stef > > > Le 6/3/16 10:54, Aliaksei Syrel a Ã©crit : >> >> In case of layout strategy it is actually questionable. Because >> it is LayoutStrategy WHO resizes. all current *Resizing objects >> define HOW strategy resizes element. From this perspective >> resizer is layout strategy. >> >> We request native English speakers :) >> >> On Mar 6, 2016 10:38 AM, "stepharo" <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi alex >> >> >> I would like rewrite >> >> exact: aNumber >> self resizing: (BlLayoutExactResizer new size: aNumber) >> >> as >> >> exact: aNumber >> self resizer: (BlLayoutExactResizer new size: aNumber) >> >> you have >> >> Object subclass: #BlLayoutAxisParams >> instanceVariableNames: 'resizing' >> classVariableNames: '' >> package: 'Bloc-Core-LayoutStrategy-Core' >> >> and the resizing method is in private protocol >> however it looks like it is used a lot outside. >> >> So >> >> should I change all the senders + protocol? >> >> Stef >> >> >> >

March 6, 2016

Re: [Pharo-dev] [Bloc] about resizing

by Aliaksei Syrel

Now it is clear and makes sense. Yes, it should be renamed! On Mar 6, 2016 11:10 AM, "stepharo" <stepharo(a)free.fr> wrote: > Wait you confuse me. > > My only point is > > - Class should not end in ing but in er > DeepCopier is not DeepCopying > PragmaCollector is not PragmaCollecting > > - So if I set (using a setter) an attribute to an object passing a resizer > the name of the setter should not be resizing: (BlLayoutExactResizer new) > > I could understand if this is a general method but the selector is not > really nice either > I would prefer in that case resizeWith: (BlLayoutExactResizer new) > > Am'I clear? > Stef > > > Le 6/3/16 10:54, Aliaksei Syrel a Ã©crit : > > In case of layout strategy it is actually questionable. Because it is > LayoutStrategy WHO resizes. all current *Resizing objects define HOW > strategy resizes element. From this perspective resizer is layout strategy. > > We request native English speakers :) > On Mar 6, 2016 10:38 AM, "stepharo" <stepharo(a)free.fr> wrote: > >> Hi alex >> >> >> I would like rewrite >> >> exact: aNumber >> self resizing: (BlLayoutExactResizer new size: aNumber) >> >> as >> >> exact: aNumber >> self resizer: (BlLayoutExactResizer new size: aNumber) >> >> you have >> >> Object subclass: #BlLayoutAxisParams >> instanceVariableNames: 'resizing' >> classVariableNames: '' >> package: 'Bloc-Core-LayoutStrategy-Core' >> >> and the resizing method is in private protocol >> however it looks like it is used a lot outside. >> >> So >> >> should I change all the senders + protocol? >> >> Stef >> >> >> >> >

March 6, 2016

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

by Esteban Lorenzano

> On 06 Mar 2016, at 10:50, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > Instead of spending a sh*tload of bytes arguing about this nonsense, let's move on to do some coding... Sorry, but this is the only reasonable thing I can rescue from this whole thread. The same discussion arises every year once or twice and is always same result: nothing, except people getting angry and trolling in every possible directionâ¦ we will *never* reach an agreement here because is a subjective matter. Is that a reason to zealot about? No (and take into account Iâm referring to all positions here, not just one side or another). So I will ask *again* too calm down and letâs talk about what is really important? This thread has now 44 mails (45 with this now)â¦ of those, just the first mail had something to do with the original purpose. Stay calm, stay coolâ¦ we are all big persons with strong opinions that deserves respect. But we are here to put that positions aside and to discuss about what we can do togetherâ¦ they can be great of dust, you decide. Esteban ps: if it helps, consider this thread as âmoderated: not constructiveâ :)

March 6, 2016

Re: [Pharo-dev] [Bloc] about resizing

by stepharo

Wait you confuse me. My only point is - Class should not end in ing but in er DeepCopier is not DeepCopying PragmaCollector is not PragmaCollecting - So if I set (using a setter) an attribute to an object passing a resizer the name of the setter should not be resizing: (BlLayoutExactResizer new) I could understand if this is a general method but the selector is not really nice either I would prefer in that case resizeWith: (BlLayoutExactResizer new) Am'I clear? Stef Le 6/3/16 10:54, Aliaksei Syrel a Ã©crit : > > In case of layout strategy it is actually questionable. Because it is > LayoutStrategy WHO resizes. all current *Resizing objects define HOW > strategy resizes element. From this perspective resizer is layout > strategy. > > We request native English speakers :) > > On Mar 6, 2016 10:38 AM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi alex > > > I would like rewrite > > exact: aNumber > self resizing: (BlLayoutExactResizer new size: aNumber) > > as > > exact: aNumber > self resizer: (BlLayoutExactResizer new size: aNumber) > > you have > > Object subclass: #BlLayoutAxisParams > instanceVariableNames: 'resizing' > classVariableNames: '' > package: 'Bloc-Core-LayoutStrategy-Core' > > and the resizing method is in private protocol > however it looks like it is used a lot outside. > > So > > should I change all the senders + protocol? > > Stef > > >

March 6, 2016

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

by stepharo

I do not know in which world you live. You are probably not exposed to students and to technology stack, techno center, hackaton and other place were developers gather and hack. You probably use Smalltalk for your hobby and this is great. I'm selling Pharo to industry and programmers and the competition is real. I'm sad because you did not get anything that I'm said. Sorry but I will not continue this thread. Now you will not force us to market Pharo the way it should. If you are not happy, put money on the consortium and come to talk to us but you will be disappointed because the complete board is thinking the same. We are marketing our future. Now I will ask to be ban from this list such recurrent discussions. Why because we all lose time and you make me losing a lot of energy and frankly I would be you I would prefer that Stephane Ducasse, the Great Energizer is focusing on producing cool videos, new books or whatever instead of talking about this "pharo is smalltalk" shit. Yes you see I spent 14 hours to go to discuss with didier and we pushed the numerical method book (that I reviewed in the past several times), with serge we edited the new version of the book, we patiently collected all the libraries over the years, we are fighting with dependencies and more. So it gives the right to do what we want and if you are not happy, I'm sorry about it but this is like that! Stef

March 6, 2016

Re: [Pharo-dev] [Bloc] about resizing

by Aliaksei Syrel

In case of layout strategy it is actually questionable. Because it is LayoutStrategy WHO resizes. all current *Resizing objects define HOW strategy resizes element. From this perspective resizer is layout strategy. We request native English speakers :) On Mar 6, 2016 10:38 AM, "stepharo" <stepharo(a)free.fr> wrote: > Hi alex > > > I would like rewrite > > exact: aNumber > self resizing: (BlLayoutExactResizer new size: aNumber) > > as > > exact: aNumber > self resizer: (BlLayoutExactResizer new size: aNumber) > > you have > > Object subclass: #BlLayoutAxisParams > instanceVariableNames: 'resizing' > classVariableNames: '' > package: 'Bloc-Core-LayoutStrategy-Core' > > and the resizing method is in private protocol > however it looks like it is used a lot outside. > > So > > should I change all the senders + protocol? > > Stef > > > >

March 6, 2016

For future version of Spotter

by stepharo

Add a menu doing GTSpotter cleanUp. GTSpotter dontShowPreview Stef

March 6, 2016