[Pharo-dev] blog post explaining the codecity visualization of pharo changes

2014-05-18 Thread Tudor Girba
Hi,

I was asked several times for how the visualization from the Pharo 3.0
announcement was created. I now put together a blog post to explain it:
http://www.humane-assessment.com/blog/communicating-changes-in-pharo-3-0

Cheers,
Doru

-- 
www.tudorgirba.com

"Every thing has its own flow"


[Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread kilon alios
while I was recording my Interval video tutorial I observed that Interval
does not behave as I would expect . Even though (1 to: 100) works as I
expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the
interval object but it does not populate it with the numbers.

I would expect it to populate the interval with the numbers or at least
fail with an error. This does not look to me like normal behaviour.

(-100 to: 1) on the other hand work as expected.

Any thoughts on this issue ?


Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread Eliot Miranda
Hi Kilon,

On May 18, 2014, at 6:32 AM, kilon alios  wrote:

> while I was recording my Interval video tutorial I observed that Interval 
> does not behave as I would expect . Even though (1 to: 100) works as I 
> expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the 
> interval object but it does not populate it with the numbers. 
> 

You have to say
1 to: -100 by: -1

> I would expect it to populate the interval with the numbers or at least fail 
> with an error. This does not look to me like normal behaviour. 
> 
> (-100 to: 1) on the other hand work as expected.
> 
> Any thoughts on this issue ? 



Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread kilon alios
yes I know, I was just wondering if that was normal behaviour because it
looks quite confusing to me.


On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda wrote:

> Hi Kilon,
>
> On May 18, 2014, at 6:32 AM, kilon alios  wrote:
>
> > while I was recording my Interval video tutorial I observed that
> Interval does not behave as I would expect . Even though (1 to: 100) works
> as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the
> interval object but it does not populate it with the numbers.
> >
>
> You have to say
> 1 to: -100 by: -1
>
> > I would expect it to populate the interval with the numbers or at least
> fail with an error. This does not look to me like normal behaviour.
> >
> > (-100 to: 1) on the other hand work as expected.
> >
> > Any thoughts on this issue ?
>
>


[Pharo-dev] Smalltalkhub project modification error

2014-05-18 Thread Attila Magyar
Hi,

When I try to modify my project information on Smalltakhub, I receive the
following error:

Oops! 
 502 Proxy Error  
Proxy Error
 The proxy server received an invalid
 response from an upstream server.
 The proxy server could not handle the request 
PUT /hub/projects/zeroflag/TDD-Kata  
. Reason: Error reading from remote server




--
View this message in context: 
http://forum.world.st/Smalltalkhub-project-modification-error-tp4759423.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread Eliot Miranda



On May 18, 2014, at 7:59 AM, kilon alios  wrote:

> yes I know, I was just wondering if that was normal behaviour because it 
> looks quite confusing to me. 

Personally I find it a natural way of expressing an empty interval.  to: is 
syntactic sugar for to:by:, and so the default of 1 for the step (the by: arg) 
is expected.

I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity 
positive (or 1 to: Float inf, ugh).

Eliot (phone)
> On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda  
> wrote:
>> Hi Kilon,
>> 
>> On May 18, 2014, at 6:32 AM, kilon alios  wrote:
>> 
>> > while I was recording my Interval video tutorial I observed that Interval 
>> > does not behave as I would expect . Even though (1 to: 100) works as I 
>> > expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the 
>> > interval object but it does not populate it with the numbers.
>> >
>> 
>> You have to say
>> 1 to: -100 by: -1
>> 
>> > I would expect it to populate the interval with the numbers or at least 
>> > fail with an error. This does not look to me like normal behaviour.
>> >
>> > (-100 to: 1) on the other hand work as expected.
>> >
>> > Any thoughts on this issue ?
> 


Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread Sven Van Caekenberghe

On 18 May 2014, at 18:50, Eliot Miranda  wrote:

> 
> 
> 
> On May 18, 2014, at 7:59 AM, kilon alios  wrote:
> 
>> yes I know, I was just wondering if that was normal behaviour because it 
>> looks quite confusing to me. 
> 
> Personally I find it a natural way of expressing an empty interval.  to: is 
> syntactic sugar for to:by:, and so the default of 1 for the step (the by: 
> arg) is expected.
> 
> I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity 
> positive (or 1 to: Float inf, ugh).

Since there is Character>>#to: you can actually write $A to: $Z although it 
returns an Array instead of a String, but that can be solved with

  ($a to: $z) as: String

or

  String withAll: ($a to: $z)

> Eliot (phone)
>> On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda  
>> wrote:
>> Hi Kilon,
>> 
>> On May 18, 2014, at 6:32 AM, kilon alios  wrote:
>> 
>> > while I was recording my Interval video tutorial I observed that Interval 
>> > does not behave as I would expect . Even though (1 to: 100) works as I 
>> > expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the 
>> > interval object but it does not populate it with the numbers.
>> >
>> 
>> You have to say
>> 1 to: -100 by: -1
>> 
>> > I would expect it to populate the interval with the numbers or at least 
>> > fail with an error. This does not look to me like normal behaviour.
>> >
>> > (-100 to: 1) on the other hand work as expected.
>> >
>> > Any thoughts on this issue ?
>> 
>> 




Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread Eliot Miranda
On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe wrote:

>
> On 18 May 2014, at 18:50, Eliot Miranda  wrote:
>
> > On May 18, 2014, at 7:59 AM, kilon alios  wrote:
> >
> >> yes I know, I was just wondering if that was normal behaviour because
> it looks quite confusing to me.
> >
> > Personally I find it a natural way of expressing an empty interval.  to:
> is syntactic sugar for to:by:, and so the default of 1 for the step (the
> by: arg) is expected.
> >
> > I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity
> positive (or 1 to: Float inf, ugh).
>
> Since there is Character>>#to: you can actually write $A to: $Z although
> it returns an Array instead of a String, but that can be solved with
>
>   ($a to: $z) as: String
>
> or
>
>   String withAll: ($a to: $z)
>

Ugh, that's really bad.  So if I want to construct an interval over the
Unicode characters this hack instantiates a large string.  The whole point
about an Interval is to compute a set of values, not construct a
collection.  If I want to construct a collection I can.

I would add a subclass of Interval, say NonArithmeticInterval, that sent
successor: step or predecessor: step so that e.g.
Character>>successor: n
^Character value: self asInteger + n




> > Eliot (phone)
> >> On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda 
> wrote:
> >> Hi Kilon,
> >>
> >> On May 18, 2014, at 6:32 AM, kilon alios  wrote:
> >>
> >> > while I was recording my Interval video tutorial I observed that
> Interval does not behave as I would expect . Even though (1 to: 100) works
> as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the
> interval object but it does not populate it with the numbers.
> >> >
> >>
> >> You have to say
> >> 1 to: -100 by: -1
> >>
> >> > I would expect it to populate the interval with the numbers or at
> least fail with an error. This does not look to me like normal behaviour.
> >> >
> >> > (-100 to: 1) on the other hand work as expected.
> >> >
> >> > Any thoughts on this issue ?
> >>
> >>
>
>
>


-- 
best,
Eliot


Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread Nicolas Cellier
2014-05-18 19:19 GMT+02:00 Eliot Miranda :

>
>
>
> On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe wrote:
>
>>
>> On 18 May 2014, at 18:50, Eliot Miranda  wrote:
>>
>> > On May 18, 2014, at 7:59 AM, kilon alios  wrote:
>> >
>> >> yes I know, I was just wondering if that was normal behaviour because
>> it looks quite confusing to me.
>> >
>> > Personally I find it a natural way of expressing an empty interval.
>>  to: is syntactic sugar for to:by:, and so the default of 1 for the step
>> (the by: arg) is expected.
>> >
>> > I'm dissatisfied however that I can't write $A to: $Z, or 1 to:
>> Infinity positive (or 1 to: Float inf, ugh).
>>
>>
It should be coupled to some lazy protocol (like Xtreams) otherwise any
selector is going to loop infinitely.


> Since there is Character>>#to: you can actually write $A to: $Z although
>> it returns an Array instead of a String, but that can be solved with
>>
>>   ($a to: $z) as: String
>>
>> or
>>
>>   String withAll: ($a to: $z)
>>
>
>
Not that it answers a String in Squeak, because this seemed a more natural
recipient than OrderedCollection to me (OrderedCollection it previously
was).


> Ugh, that's really bad.  So if I want to construct an interval over the
> Unicode characters this hack instantiates a large string.  The whole point
> about an Interval is to compute a set of values, not construct a
> collection.  If I want to construct a collection I can.
>
> I would add a subclass of Interval, say NonArithmeticInterval, that sent
> successor: step or predecessor: step so that e.g.
> Character>>successor: n
> ^Character value: self asInteger + n
>
>
>
Oh yes, that's coming directly from ASCII era when it did not matter.
... but then also to:do: and inlined variants will have to be hacked.
Wouldn't the cost be a bit prohibitive?


>
>
>> > Eliot (phone)
>> >> On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda <
>> eliot.mira...@gmail.com> wrote:
>> >> Hi Kilon,
>> >>
>> >> On May 18, 2014, at 6:32 AM, kilon alios 
>> wrote:
>> >>
>> >> > while I was recording my Interval video tutorial I observed that
>> Interval does not behave as I would expect . Even though (1 to: 100) works
>> as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the
>> interval object but it does not populate it with the numbers.
>> >> >
>> >>
>> >> You have to say
>> >> 1 to: -100 by: -1
>> >>
>> >> > I would expect it to populate the interval with the numbers or at
>> least fail with an error. This does not look to me like normal behaviour.
>> >> >
>> >> > (-100 to: 1) on the other hand work as expected.
>> >> >
>> >> > Any thoughts on this issue ?
>> >>
>> >>
>>
>>
>>
>
>
> --
> best,
> Eliot
>


Re: [Pharo-dev] Intervals behaviour for negative numbers, normal or bug ?

2014-05-18 Thread Eliot Miranda
On Sun, May 18, 2014 at 11:55 AM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
>
> 2014-05-18 19:19 GMT+02:00 Eliot Miranda :
>
>
>>
>>
>> On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe wrote:
>>
>>>
>>> On 18 May 2014, at 18:50, Eliot Miranda  wrote:
>>>
>>> > On May 18, 2014, at 7:59 AM, kilon alios 
>>> wrote:
>>> >
>>> >> yes I know, I was just wondering if that was normal behaviour because
>>> it looks quite confusing to me.
>>> >
>>> > Personally I find it a natural way of expressing an empty interval.
>>>  to: is syntactic sugar for to:by:, and so the default of 1 for the step
>>> (the by: arg) is expected.
>>> >
>>> > I'm dissatisfied however that I can't write $A to: $Z, or 1 to:
>>> Infinity positive (or 1 to: Float inf, ugh).
>>>
>>>
> It should be coupled to some lazy protocol (like Xtreams) otherwise any
> selector is going to loop infinitely.
>

Of course it should.  But there are other things.  For examp,le,
Smalltalk-80 had an InfiniteForm and it always bugged me that
InfiniteForm>>extent answered SmallInteger maxVal@SmallInteger maxVal.  If
one changed that to answer Infinity positive@Infinity positive it was
Interval code that broke.  So (at least in my image) I fixed the Interval
code.  Intervals are really useful for modelling things, not just iterating.


>
>>  Since there is Character>>#to: you can actually write $A to: $Z
>>> although it returns an Array instead of a String, but that can be solved
>>> with
>>>
>>>   ($a to: $z) as: String
>>>
>>> or
>>>
>>>   String withAll: ($a to: $z)
>>>
>>
>>
> Not that it answers a String in Squeak, because this seemed a more natural
> recipient than OrderedCollection to me (OrderedCollection it previously
> was).
>
>
>> Ugh, that's really bad.  So if I want to construct an interval over the
>> Unicode characters this hack instantiates a large string.  The whole point
>> about an Interval is to compute a set of values, not construct a
>> collection.  If I want to construct a collection I can.
>>
>> I would add a subclass of Interval, say NonArithmeticInterval, that sent
>> successor: step or predecessor: step so that e.g.
>> Character>>successor: n
>> ^Character value: self asInteger + n
>>
>>
>>
> Oh yes, that's coming directly from ASCII era when it did not matter.
> ... but then also to:do: and inlined variants will have to be hacked.
> Wouldn't the cost be a bit prohibitive?
>

The inlined versions need only to work with integers.  to:by:do: is a
different animal to to:by:.  Once we have a good adaptive optimizer the
answer can be different, but for now...




> > Eliot (phone)
>>> >> On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda <
>>> eliot.mira...@gmail.com> wrote:
>>> >> Hi Kilon,
>>> >>
>>> >> On May 18, 2014, at 6:32 AM, kilon alios 
>>> wrote:
>>> >>
>>> >> > while I was recording my Interval video tutorial I observed that
>>> Interval does not behave as I would expect . Even though (1 to: 100) works
>>> as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the
>>> interval object but it does not populate it with the numbers.
>>> >> >
>>> >>
>>> >> You have to say
>>> >> 1 to: -100 by: -1
>>> >>
>>> >> > I would expect it to populate the interval with the numbers or at
>>> least fail with an error. This does not look to me like normal behaviour.
>>> >> >
>>> >> > (-100 to: 1) on the other hand work as expected.
>>> >> >
>>> >> > Any thoughts on this issue ?
>>> >>
>>> >>
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>


-- 
best,
Eliot


Re: [Pharo-dev] a Pharo talk from a ruby conference

2014-05-18 Thread Esteban A. Maringolo
Just to add some fuel to this fire... this is a quote from the summary
of the latest LightTable's blog post :

"a smooth interface to the old world so we don't end up sharing a
grave with smalltalk"

I agree with many things in the post.  But they're taking credit for
old ideas disguised as the latest innovation.


Regards,


Esteban A. Maringolo


2014-05-17 8:13 GMT-03:00 kilon alios :
> I don't get why C is not old / deprecated / obsolete . Afterall its as old
> as Smalltalk
>
> Who really uses modern languages ?
>
> C - 1972
>
> Python - 1991
>
> C++ - 1983
>
> Pascal - 1970
>
> .NET - 2002
>
> Lisp - 1958
>
> Java - 1995
>
> Ruby - 1995
>
> Perl - 1987
>
> Visual Basic - 1991
>
> Javascript - 1995
>
> Objective C- 1983
>
> PHP - 1995
>
>
> The vast majority of all popular languages out there are at least 20 years
> old. Thats ancient history. They are not old, they are dinosaurs. Even
> Clojure is 7 years old.
>
> The problem I see here is that the vast majority of things people are going
> to like in Pharo on a basic level are Smalltalk features. Implementation
> wise Pharo has improved a lot of things, added new stuff etc etc. But if you
> take a look at for example Python back in 1991 and you compare it with a
> recent version of Python you will find tons of diffirences. Yet its still
> Python.
>
> Actually its impossible to run a hello world of an old python (anything
> previous to version 3) that will run in the recent Python. Cause they
> changed print "hello World" to print( "hello World") , we are talking here
> about fundamental changes.
>
> Personally I don't see how Pharo being 100% Smalltalk makes it unable or
> difficult to implement super modern and efficient new features. Languages
> and Software is not written in stone, it continuously evolves and improves
> or else people stop using it. Vim was created back in 1991 people still find
> awesome, modern, extremely powerful.
>
> this is from Ruby's website -> "Ruby is a language of careful balance. Its
> creator, Yukihiro “Matz” Matsumoto, blended parts of his favorite languages
> (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that
> balanced functional programming with imperative programming." Ruby has the
> right to be called Smalltalk-inspired. because thats what it is.
>
> You got every right to describe Pharo any way you like but for me Pharo is
> "a modern implementation of Smalltalk. A visual environment for easy direct
> live coding" .
>
>
> On Sat, May 17, 2014 at 12:30 PM, Hilaire Fernandes
>  wrote:
>>
>>
>>
>> Le 16/05/2014 20:18, p...@highoctane.be a écrit :
>> >
>> > Back to the future after 30 years of spinning your wheels
>> > ---
>> >
>> > Wanting to code at the speed of tought?
>> > Wishing the machine was your friend and not a roadblock?
>> > Want to burn cash as slow as possible while maximizing your output?
>> >
>> > If so, get a copy of Pharo! It is not your (grand) daddy's Smalltalk!
>>
>> That's why I understand this argument about not advertising Smalltalk in
>> Pharo.
>>
>> Whatever we do or say, this huge mass of followers, once they heard
>> Smalltalk they fill their head with red light warning, Smalltalk =
>> old/deprecated/obsolete.
>>
>> For Pharo willing to socially scale = need to take this in consideration.
>>
>> Hilaire
>> --
>> Dr. Geo http://drgeo.eu
>>
>>
>



Re: [Pharo-dev] a Pharo talk from a ruby conference

2014-05-18 Thread Sebastian Sastre
that article lost me when it wrote then instead of than

sebastian

o/

> On 18/05/2014, at 17:09, "Esteban A. Maringolo"  wrote:
> 
> Just to add some fuel to this fire... this is a quote from the summary
> of the latest LightTable's blog post :
> 
> "a smooth interface to the old world so we don't end up sharing a
> grave with smalltalk"
> 
> I agree with many things in the post.  But they're taking credit for
> old ideas disguised as the latest innovation.
> 
> 
> Regards,
> 
> 
> Esteban A. Maringolo
> 
> 
> 2014-05-17 8:13 GMT-03:00 kilon alios :
>> I don't get why C is not old / deprecated / obsolete . Afterall its as old
>> as Smalltalk
>> 
>> Who really uses modern languages ?
>> 
>> C - 1972
>> 
>> Python - 1991
>> 
>> C++ - 1983
>> 
>> Pascal - 1970
>> 
>> .NET - 2002
>> 
>> Lisp - 1958
>> 
>> Java - 1995
>> 
>> Ruby - 1995
>> 
>> Perl - 1987
>> 
>> Visual Basic - 1991
>> 
>> Javascript - 1995
>> 
>> Objective C- 1983
>> 
>> PHP - 1995
>> 
>> 
>> The vast majority of all popular languages out there are at least 20 years
>> old. Thats ancient history. They are not old, they are dinosaurs. Even
>> Clojure is 7 years old.
>> 
>> The problem I see here is that the vast majority of things people are going
>> to like in Pharo on a basic level are Smalltalk features. Implementation
>> wise Pharo has improved a lot of things, added new stuff etc etc. But if you
>> take a look at for example Python back in 1991 and you compare it with a
>> recent version of Python you will find tons of diffirences. Yet its still
>> Python.
>> 
>> Actually its impossible to run a hello world of an old python (anything
>> previous to version 3) that will run in the recent Python. Cause they
>> changed print "hello World" to print( "hello World") , we are talking here
>> about fundamental changes.
>> 
>> Personally I don't see how Pharo being 100% Smalltalk makes it unable or
>> difficult to implement super modern and efficient new features. Languages
>> and Software is not written in stone, it continuously evolves and improves
>> or else people stop using it. Vim was created back in 1991 people still find
>> awesome, modern, extremely powerful.
>> 
>> this is from Ruby's website -> "Ruby is a language of careful balance. Its
>> creator, Yukihiro “Matz” Matsumoto, blended parts of his favorite languages
>> (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that
>> balanced functional programming with imperative programming." Ruby has the
>> right to be called Smalltalk-inspired. because thats what it is.
>> 
>> You got every right to describe Pharo any way you like but for me Pharo is
>> "a modern implementation of Smalltalk. A visual environment for easy direct
>> live coding" .
>> 
>> 
>> On Sat, May 17, 2014 at 12:30 PM, Hilaire Fernandes
>>  wrote:
>>> 
>>> 
>>> 
>>> Le 16/05/2014 20:18, p...@highoctane.be a écrit :
 
 Back to the future after 30 years of spinning your wheels
 ---
 
 Wanting to code at the speed of tought?
 Wishing the machine was your friend and not a roadblock?
 Want to burn cash as slow as possible while maximizing your output?
 
 If so, get a copy of Pharo! It is not your (grand) daddy's Smalltalk!
>>> 
>>> That's why I understand this argument about not advertising Smalltalk in
>>> Pharo.
>>> 
>>> Whatever we do or say, this huge mass of followers, once they heard
>>> Smalltalk they fill their head with red light warning, Smalltalk =
>>> old/deprecated/obsolete.
>>> 
>>> For Pharo willing to socially scale = need to take this in consideration.
>>> 
>>> Hilaire
>>> --
>>> Dr. Geo http://drgeo.eu
> 



[Pharo-dev] WhatsUp from: 2014-05-19 until: 2014-05-31

2014-05-18 Thread seaside
Hi! We're sending this automatic email twice a month, to give the community an 
opportunity to easily know what's happening and to coordinate efforts.  Just 
answer informally, and feel free to spawn discussions thereafter!

### Here's what I've been up to since the last WhatsUp:

- $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS

### What's next, until 2014-05-31 (*):

- $NEXT_STEPS_TOWARDS_WORLD_DOMINATION

(*) we'll be expecting results by then ;)



Re: [Pharo-dev] WhatsUp from: 2014-05-19 until: 2014-05-31

2014-05-18 Thread stepharo



Hi! We're sending this automatic email twice a month, to give the community an 
opportunity to easily know what's happening and to coordinate efforts.  Just 
answer informally, and feel free to spawn discussions thereafter!

### Here's what I've been up to since the last WhatsUp:





### What's next, until 2014-05-31 (*)


   -  continue to work on laser book tutorial
   -  continue to analyze font mess.
   - sync for 40