Re: [Pharo-dev] R: [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

[Sven Van Caekenberghe]

On 27 Jun 2014, at 01:21, Facundo Vozzi  wrote:

> Incredible Work!

You're welcome.

> Thanks for sharing,
> FV
> 
> p.s.: I used one HP-35 at school from my father. I love the RPN method when I 
> understood it :-)

You are actually the first real person that I heard of that used one ! Cool.

> On Thu, Jun 26, 2014 at 5:13 AM, Sven Van Caekenberghe  wrote:
> 
> On 26 Jun 2014, at 09:24, Lorenzo Schiavina  wrote:
> 
> > Great job Sven, I felt young again.
> >
> > Thank you.
> >
> > Lorenzo
> 
> Yeah, I am beginning to realise that being interested in historic calculators 
> puts you in a certain age bracket ;-)
> 
> I am glad you liked it.
> 
> Sven
> 
> 
> 

Re: [Pharo-dev] about ~=

[Andres Valloud]

Sp, speaking of mathematical precedence and all that, anyone up to 
looking at the IEEE-754 spec and making one's Smalltalk of choice comply 
with _all_ the requirements?  Or how about implementing decimal floats?


On 6/26/14 12:01 , p...@highoctane.be wrote:


Couldn't we just have an expression evaluator done with PetitParser
doing these things?

Tcl and Bash have this expr: thing.


(Expression parse: '5+3*2') value.
(Expression parse: ':a | 5+:a*2') value:10.
(Expression parse: ':a | 5+:a*2') value:self x.

With the thesis of Lukas Renggli these was this Helvetia story.
Is there any chance we see something around these lines now that there
is a new compiler thing inside Pharo?

So:

someMethod: anX

^ 5 + anX * 2

Phil





On Thu, Jun 26, 2014 at 6:11 PM, Richard Sargent
mailto:richard.sarg...@gemtalksystems.com>> wrote:

Esteban A. Maringolo wrote
 > If one thing confuses people in that realm is non arithmetic
precedence:
 > Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.
 >
 > And we're not going to change that either. It's not worthy, and I
 > doubt if it is possible at all.

I'm probably late to the party with this reply. The primary reason
for not
changing this is that it would be incorrect. It comes down to intrinsic
versus extrinsic meaning. A multiple operator has an intrinsic
meaning: it
means multiple. But a message name does not have intrinsic meaning
(other
than it is a good idea to have the name represent what it does). The
meaning
of a message is determined by the receiver. e.g. if PetitParser
defines #*
to mean "0 or more repetitions", what happens when someone has
decided that
it should be evaluated before #+?

Message sending precedence can only be defined in terms of the type of
message: unary, binary (or infix), and keyword, since the
interpretation of
the message is the receiver's responsibility, not the compiler's.




--
View this message in context:
http://forum.world.st/about-tp4764892p4765070.html
Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.

Re: [Pharo-dev] super initialize

[Stefan Marr]

Hi:

On 26 Jun 2014, at 18:48, stepharo  wrote:

> I prefer to have a super call for consistency reasons. Igor jokes me usually 
> on that.
> Now there should not be an initialize in ProtoObject and Object in the future.

Just curios, what’s the reasoning behind not having #initialize in Object? 
Initialization isn’t a core concept Object should support?

I am asking because in SOM, Object indeed does not have #initialize, and well, 
I find that a little annoying.
Because often enough I need to add a #new method that sends #initialize, but 
since it is not available implicitly everywhere, the system is rather 
inconsistent in that regard. Different classes end up using slightly different 
approaches to initialization, which is confusing.

Best regards
Stefan

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

Sven,

You don't believe that it is worthwhile ... that's okay ... you are
entitled to your beliefs.

Frankly, when you integrate git into a Smalltalk environment (and I have)
you are not messing with 100's of little files ... you are working with
methods and packages and classes ... the stuff that Smalltalk programmers
work with every day ... and I don't even think about how the source is
being stored because in my environment I work with methods, classes and
packages and I rarely look at the disk (just like most Smalltalk
programmers and unlike most Java/C#/Go programmers:)...

Git brings another dimension to my smalltalk development experience in a
couple of very critical areas, so I don't have to believe, I know...

I do believe that it is worthwhile to integrate git into Smalltalk
development environments and I'm doing something about that and I am
willing to help other folks with similar beliefs ...

So at the end of the day you can be as negative or as positive as you like
and I will continue to plug away:)

Dale






On Thu, Jun 26, 2014 at 2:04 PM, Sven Van Caekenberghe  wrote:

>
> On 26 Jun 2014, at 22:28, p...@highoctane.be wrote:
>
> >
> > Le 26 juin 2014 21:54, "Esteban Lorenzano"  a
> écrit :
> > >
> > >
> > > On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:
> > >
> > > > I know you, and some others, have that opinion and that is OK.
> > > > I also think that it would be nice to have (better git integration).
> > > >
> > > > But we essentially have it today, although a bit cumbersome, awkward
> (cfr https://github.com/pharo-project/pharo-core). Some of us store all
> their code in git all the time.
> > > >
> > > > My opinion is that it is not per se the most important thing. We
> have to focus on the aspects where we are better, not try being more the
> same as everybody else.
> > > >
> > > > We need modularisation, better tools, new ways of working with live
> objects, new interactive representations, mouldable tools, remote image
> tools, automatic cloud deploys, magic stuff, ..
> > >
> > > yes… and better git integration is part of “better tools”.
> > > and IMO, with the “plus” that it can boost the other areas.
> >
> > Yes, Git enables all of code and assets in one single place and tooling
> that helps a lot with changes ( e.g. gitk ). That is huge in practice.
>
> I know that there are lots of git tools out there, but how do these help -
> they are disconnected from the image, and thus disconnected from our
> regular way of working (senders, implementors, references, ...).
>
> The current source code format in git is cool, but can you manage a merge
> or diff like that, with all the different parts scattered over 10s, 100s of
> files, with no matter what tool ? Apart from the fact that such bigger
> merge is always very difficult, no other tools will support our world view,
> ever.
>
>
> https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5
>
> You and I understand the above, no Java/C#/Go programmer will.
>
> The next discussion will be: what are all those silly method files, why
> not put them all in one file ? Then the question is, what are all those
> silly exclamation marks in our file out format ? And so on.
>
> I don't want to sound too negative, I just don't belief it will actually
> make that much difference.
>
> > Phil
> >
> > >
> > > Esteban
> > >
> > > >
> > > > On 26 Jun 2014, at 20:52, Esteban Lorenzano 
> wrote:
> > > >
> > > >>
> > > >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe 
> wrote:
> > > >>
> > > >>>
> > > >>> On 26 Jun 2014, at 19:07, Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
> > > >>>
> > >  I think that it is possible to most if not all of the git work
> support into the Smalltalk development environment ... I am doing that for
> GemStone with tODE[6] and I do find myself going to the go to the command
> line much less frequently ... but in tODE I have built a git merge tool and
> a git diff tool ... you can get the git history of a method from the
> browser, etc.
> > > 
> > >  Without a relatively high degree of tool integration it can be
> clunky to use git ... I am very willing to share what I've done/learned in
> tODE with Pharo tool builders and of course I think Thierry Goubier has
> actually been ahead of me in several different areas ...
> > > >>>
> > > >>> That is my analysis: it works today, 'perfectly', but there is not
> enough tools support to make it as easy as Monticello as a whole is today.
> > > >>>
> > > >>> If these tools exist, or we can build them quickly based Dale's
> code, that would be cool (I guess its all OSProcess underneath, which I
> find so/so, a direct integration is better) that would be good.
> > > >>>
> > > >>> Would having this change our world fundamentally ? No, IMHO
> > > >>> Is it worth the effort, is the ROI there ? I don't think so
> > > >>
> > > >> I disagree here. I think moving our development to git will change
> deeply (for good) our co

Re: [Pharo-dev] How to get started with Git and Pharo?

[Richard Sargent]

Sven Van Caekenberghe-2 wrote
> The current source code format in git is cool, but can you manage a merge
> or diff like that, with all the different parts scattered over 10s, 100s
> of files, with no matter what tool ? Apart from the fact that such bigger
> merge is always very difficult, no other tools will support our world
> view, ever. 
> 
> ...
> 
> I don't want to sound too negative, I just don't belief it will actually
> make that much difference.

I've seen the work that Dale's done with tODE. Can you manage a merge with
so many files? Yes, without a doubt. Does git do an excellent job of merging
and differencing? Absolutely.


In terms of making a difference, I'm of the opinion that git provides
something modern, universal, and comparable to ENVY (which I have used for
most of the last 20 years and admire immensely).

Are there more important things to do? Without a doubt. Is this worth too
little to bother with? Absolutely not. git will facilitate configuration
management (not just versionning) and will also greatly facilitate
cross-dialect compatibility. The ability to easily pick up an offering from
one Smalltalk and fork it with small changes for another dialect will be
nirvana for many of us.





--
View this message in context: 
http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p4765178.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sebastian Sastre]

On Jun 26, 2014, at 7:58 PM, Sven Van Caekenberghe  wrote:

> @Sebastian
> 
> So we are on github, gemstone even more, cuis too. And Squeak is not. Did 
> anything change dramatically ?
> 
> There are thousands of languages and systems on github, I like it too, but 
> just being there makes little difference. It is just a tool, a good one, but 
> no more.

It’s a tool that isn’t too interesting as tool

But it is in the part that it leverages the social aspect of coding

Dramatic changes why expect that?

You are only creating the chances to make your code more accessible and less 
alien to fresh eyes

Did I say social already? 

Should say social one more time? like when people talk about things and 
collaboration might emerge?

Re: [Pharo-dev] R: [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

[Facundo Vozzi]

Incredible Work!

Thanks for sharing,
FV

p.s.: I used one HP-35 at school from my father. I love the RPN method when
I understood it :-)



On Thu, Jun 26, 2014 at 5:13 AM, Sven Van Caekenberghe  wrote:

>
> On 26 Jun 2014, at 09:24, Lorenzo Schiavina  wrote:
>
> > Great job Sven, I felt young again.
> >
> > Thank you.
> >
> > Lorenzo
>
> Yeah, I am beginning to realise that being interested in historic
> calculators puts you in a certain age bracket ;-)
>
> I am glad you liked it.
>
> Sven
>
>
>

Re: [Pharo-dev] spec question

[Pablo R. Digonzelli]

For example, it works 

m := DynamicComposableModel new. 
m instantiateModels: #(listModel ListModel ). 
m listModel backgroundColorBlock: [ Color blue ]. 
m listModel displayBlock: [ :it | it printString]. 

l := ( SpecLayout composed newRow: #listModel ; yourself ). 

m listModel items: (1 to: 10). 
m listModel backgroundColorBlock: [:item :index | Color blue]. 
m layout: l. 
m openWithSpec . 

but it does not work 

m := DynamicComposableModel new. 
m instantiateModels: #(listModel MultiColumnListModel ). 
m listModel backgroundColorBlock: [ Color blue ]. 
m listModel displayBlock: [ :it | { it printString. it printString} ]. 

l := ( SpecLayout composed newRow: #listModel ; yourself ). 

m listModel items: (1 to: 10). 
m listModel backgroundColorBlock: [:item :index | Color blue]. 
m layout: l. 
m openWithSpec . 

TIA 


Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

- Mensaje original -

De: "Pablo R. Digonzelli"  
Para: "Pharo Development List"  
Enviados: Jueves, 26 de Junio 2014 19:53:06 
Asunto: Re: [Pharo-dev] spec question 

Someone knows how to set backgroundColorBlock: in an MultiColumnListBox?. 

TIA 


Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

- Mensaje original -

De: "Pablo R. Digonzelli"  
Para: nicolaih...@web.de, "Pharo Development List"  
Enviados: Jueves, 26 de Junio 2014 19:13:57 
Asunto: Re: [Pharo-dev] spec question 

thanks Nicolai! 



Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

- Mensaje original -

De: "Nicolai Hess"  
Para: "Pharo Development List"  
CC: "Any question about pharo is welcome"  
Enviados: Jueves, 26 de Junio 2014 18:55:26 
Asunto: Re: [Pharo-dev] spec question 


2014-06-26 23:13 GMT+02:00 Pablo R. Digonzelli < pdigonze...@gmail.com > : 




Hi all, two questions about Spec. 

1) How can i change the font for a ListModel or TextModel? 

2) I try , but nothing happend . I does not work but there is no error also 

l := ListModel new. 
l backgroundColorBlock: [ Color red ]. 
l openWithSpec . 

Can I change de backcolor of ListModel ? 

Sorry for my english. 

TIA 




Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 







About the font: I don't know if this is possible. 

For the background color: 

This works only for the background of the list cells. If there is no entry 
in your listmodel list, the list view is empty as well and there is nothing 
to show. 

This works: 

ListModel new 
items: (1 to: 10); 
backgroundColorBlock: [ :item :index |Color red ]; 
openWithSpec. 

or with more colors :) 

ListModel new 
items: Color registeredColorNames ; 
backgroundColorBlock: [ :item :index | Color named:item]; 
openWithSpec. 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

That is cool, but you/we can do that today, Pharo's full source is on github 
for quite some time now.

@Sebastian

So we are on github, gemstone even more, cuis too. And Squeak is not. Did 
anything change dramatically ?

There are thousands of languages and systems on github, I like it too, but just 
being there makes little difference. It is just a tool, a good one, but no more.

On 27 Jun 2014, at 00:16, Dale Henrichs  
wrote:

> My favorite feature by far is the ability to look at the git history of the 
> methods themselves ... just the other day I had a bug that I was tracking 
> down, and by looking at the git history I discovered that a critical change 
> had been made to that method 1 year 12 days ago ... from that I was able to 
> look at all of the changes to all of the packages that had been made in the 
> same commit (the critical code had not only been moved to a different class 
> but the critical method had been moved to a separate package ... and from 
> that I was able to see that a bug had been introduced when not all of the 
> critical method was moved ... bug fixed ...
> 
> Besides method versions, you can look at the git history for a class, package 
> or metacello project  these are thing that would take a bit of work to 
> accomplish using just Monticello ... and if you were to attempt to do it, the 
> simplest thing to do would be to copy all of the packages into a git 
> repository and just use git:) Frank Shearar wrote some code that did 
> something along these lines a couple of years ago ...
> 
> Dale
> 
> 
> 
> On Thu, Jun 26, 2014 at 2:21 PM, kilon alios  wrote:
> another advantage of git is source code searches. It will essentially allow 
> pharoers to search pharo code online and not just being isolated in their 
> image. The search does not return just a whole library but even code 
> fragments. 
> 
> 
> On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre 
>  wrote:
> 
> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano  wrote:
> 
>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>>> wrote:
>>> 
 I think that it is possible to most if not all of the git work support 
 into the Smalltalk development environment ... I am doing that for 
 GemStone with tODE[6] and I do find myself going to the go to the command 
 line much less frequently ... but in tODE I have built a git merge tool 
 and a git diff tool ... you can get the git history of a method from the 
 browser, etc. 
 
 Without a relatively high degree of tool integration it can be clunky to 
 use git ... I am very willing to share what I've done/learned in tODE with 
 Pharo tool builders and of course I think Thierry Goubier has actually 
 been ahead of me in several different areas ...
>>> 
>>> That is my analysis: it works today, 'perfectly', but there is not enough 
>>> tools support to make it as easy as Monticello as a whole is today.
>>> 
>>> If these tools exist, or we can build them quickly based Dale's code, that 
>>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>>> direct integration is better) that would be good.
>>> 
>>> Would having this change our world fundamentally ? No, IMHO
>>> Is it worth the effort, is the ROI there ? I don't think so
>> 
>> I disagree here. I think moving our development to git will change deeply 
>> (for good) our community processes and then I think it totally worths the 
>> effort. 
> 
> 
> big +1 here
> 
> The social benefit of having your code exposed in places like github 
> outweighs by at an astronomical scale the current lack of amazing mergetools
> 
> If your code cannot be exposed without friction you’re done 
> 
> The noise of the jungle of 
> 3-new-libraries-per-day-that-can-be-installed-in-one-shot will make your work 
> invisible
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] spec question

[Pablo R. Digonzelli]

Someone knows how to set backgroundColorBlock: in an MultiColumnListBox?. 

TIA 


Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

- Mensaje original -

De: "Pablo R. Digonzelli"  
Para: nicolaih...@web.de, "Pharo Development List"  
Enviados: Jueves, 26 de Junio 2014 19:13:57 
Asunto: Re: [Pharo-dev] spec question 

thanks Nicolai! 



Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

- Mensaje original -

De: "Nicolai Hess"  
Para: "Pharo Development List"  
CC: "Any question about pharo is welcome"  
Enviados: Jueves, 26 de Junio 2014 18:55:26 
Asunto: Re: [Pharo-dev] spec question 


2014-06-26 23:13 GMT+02:00 Pablo R. Digonzelli < pdigonze...@gmail.com > : 




Hi all, two questions about Spec. 

1) How can i change the font for a ListModel or TextModel? 

2) I try , but nothing happend . I does not work but there is no error also 

l := ListModel new. 
l backgroundColorBlock: [ Color red ]. 
l openWithSpec . 

Can I change de backcolor of ListModel ? 

Sorry for my english. 

TIA 




Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 







About the font: I don't know if this is possible. 

For the background color: 

This works only for the background of the list cells. If there is no entry 
in your listmodel list, the list view is empty as well and there is nothing 
to show. 

This works: 

ListModel new 
items: (1 to: 10); 
backgroundColorBlock: [ :item :index |Color red ]; 
openWithSpec. 

or with more colors :) 

ListModel new 
items: Color registeredColorNames ; 
backgroundColorBlock: [ :item :index | Color named:item]; 
openWithSpec. 

Re: [Pharo-dev] spec question

[Pablo R. Digonzelli]

thanks Nicolai! 



Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

- Mensaje original -

De: "Nicolai Hess"  
Para: "Pharo Development List"  
CC: "Any question about pharo is welcome"  
Enviados: Jueves, 26 de Junio 2014 18:55:26 
Asunto: Re: [Pharo-dev] spec question 


2014-06-26 23:13 GMT+02:00 Pablo R. Digonzelli < pdigonze...@gmail.com > : 




Hi all, two questions about Spec. 

1) How can i change the font for a ListModel or TextModel? 

2) I try , but nothing happend . I does not work but there is no error also 

l := ListModel new. 
l backgroundColorBlock: [ Color red ]. 
l openWithSpec . 

Can I change de backcolor of ListModel ? 

Sorry for my english. 

TIA 




Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 







About the font: I don't know if this is possible. 

For the background color: 

This works only for the background of the list cells. If there is no entry 
in your listmodel list, the list view is empty as well and there is nothing 
to show. 

This works: 

ListModel new 
items: (1 to: 10); 
backgroundColorBlock: [ :item :index |Color red ]; 
openWithSpec. 

or with more colors :) 

ListModel new 
items: Color registeredColorNames ; 
backgroundColorBlock: [ :item :index | Color named:item]; 
openWithSpec. 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

My favorite feature by far is the ability to look at the git history of the
methods themselves ... just the other day I had a bug that I was tracking
down, and by looking at the git history I discovered that a critical change
had been made to that method 1 year 12 days ago ... from that I was able to
look at all of the changes to all of the packages that had been made in the
same commit (the critical code had not only been moved to a different class
but the critical method had been moved to a separate package ... and from
that I was able to see that a bug had been introduced when not all of the
critical method was moved ... bug fixed ...

Besides method versions, you can look at the git history for a class,
package or metacello project  these are thing that would take a bit of
work to accomplish using just Monticello ... and if you were to attempt to
do it, the simplest thing to do would be to copy all of the packages into a
git repository and just use git:) Frank Shearar wrote some code that did
something along these lines a couple of years ago ...

Dale



On Thu, Jun 26, 2014 at 2:21 PM, kilon alios  wrote:

> another advantage of git is source code searches. It will essentially
> allow pharoers to search pharo code online and not just being isolated in
> their image. The search does not return just a whole library but even code
> fragments.
>
>
> On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre <
> sebast...@flowingconcept.com> wrote:
>
>>
>> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano 
>> wrote:
>>
>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>>
>>
>> On 26 Jun 2014, at 19:07, Dale Henrichs 
>> wrote:
>>
>> I think that it is possible to most if not all of the git work support
>> into the Smalltalk development environment ... I am doing that for GemStone
>> with tODE[6] and I do find myself going to the go to the command line much
>> less frequently ... but in tODE I have built a git merge tool and a git
>> diff tool ... you can get the git history of a method from the browser, etc.
>>
>>
>> Without a relatively high degree of tool integration it can be clunky to
>> use git ... I am very willing to share what I've done/learned in tODE with
>> Pharo tool builders and of course I think Thierry Goubier has actually been
>> ahead of me in several different areas ...
>>
>>
>> That is my analysis: it works today, 'perfectly', but there is not enough
>> tools support to make it as easy as Monticello as a whole is today.
>>
>> If these tools exist, or we can build them quickly based Dale's code,
>> that would be cool (I guess its all OSProcess underneath, which I find
>> so/so, a direct integration is better) that would be good.
>>
>> Would having this change our world fundamentally ? No, IMHO
>> Is it worth the effort, is the ROI there ? I don't think so
>>
>>
>> I disagree here. I think moving our development to git will change deeply
>> (for good) our community processes and then I think it totally worths the
>> effort.
>>
>>
>>
>> big +1 here
>>
>> The social benefit of having your code exposed in places like github
>> outweighs by at an astronomical scale the current lack of amazing mergetools
>>
>> If your code cannot be exposed without friction you’re done
>>
>> The noise of the jungle of
>> 3-new-libraries-per-day-that-can-be-installed-in-one-shot *will* make
>> your work invisible
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] spec question

[Nicolai Hess]

2014-06-26 23:13 GMT+02:00 Pablo R. Digonzelli :

>
> Hi all, two questions about Spec.
>
> 1) How can i change the font for a ListModel or TextModel?
>
> 2)  I try , but nothing happend . I does not work but there is no error
> also
>
> l := ListModel new.
> l backgroundColorBlock: [ Color red ].
> l openWithSpec .
>
> Can I change de backcolor of ListModel ?
>
> Sorry for my english.
>
> TIA
>
>
>
> --
> *Ing. Pablo Digonzelli*
> Software Solutions
> IP-Solutiones SRL
> Metrotec SRL
> 25 de Mayo 521
> Email: pdigonze...@softsargentina.com
> pdigonze...@gmail.com
> Cel: 5493815982714
>
>
>

About the font: I don't know if this is possible.

For the background color:

This works only for the background of the list cells. If there is no entry
in your listmodel list, the list view is empty as well and there is nothing
to show.

This works:

ListModel new
items: (1 to: 10);
backgroundColorBlock: [ :item :index |Color red ];
openWithSpec.

or with more colors :)

ListModel new
items: Color registeredColorNames ;
backgroundColorBlock: [ :item :index | Color named:item];
openWithSpec.

Re: [Pharo-dev] How to get started with Git and Pharo?

[kilon alios]

another advantage of git is source code searches. It will essentially allow
pharoers to search pharo code online and not just being isolated in their
image. The search does not return just a whole library but even code
fragments.


On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano 
> wrote:
>
> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>
>
> On 26 Jun 2014, at 19:07, Dale Henrichs 
> wrote:
>
> I think that it is possible to most if not all of the git work support
> into the Smalltalk development environment ... I am doing that for GemStone
> with tODE[6] and I do find myself going to the go to the command line much
> less frequently ... but in tODE I have built a git merge tool and a git
> diff tool ... you can get the git history of a method from the browser, etc.
>
>
> Without a relatively high degree of tool integration it can be clunky to
> use git ... I am very willing to share what I've done/learned in tODE with
> Pharo tool builders and of course I think Thierry Goubier has actually been
> ahead of me in several different areas ...
>
>
> That is my analysis: it works today, 'perfectly', but there is not enough
> tools support to make it as easy as Monticello as a whole is today.
>
> If these tools exist, or we can build them quickly based Dale's code, that
> would be cool (I guess its all OSProcess underneath, which I find so/so, a
> direct integration is better) that would be good.
>
> Would having this change our world fundamentally ? No, IMHO
> Is it worth the effort, is the ROI there ? I don't think so
>
>
> I disagree here. I think moving our development to git will change deeply
> (for good) our community processes and then I think it totally worths the
> effort.
>
>
>
> big +1 here
>
> The social benefit of having your code exposed in places like github
> outweighs by at an astronomical scale the current lack of amazing mergetools
>
> If your code cannot be exposed without friction you’re done
>
> The noise of the jungle of
> 3-new-libraries-per-day-that-can-be-installed-in-one-shot *will* make
> your work invisible
>
>
>
>
>

Re: [Pharo-dev] Configuration critical warnings and errors in 40047

[stepharo]

thanks this is a really nice script!


On 26/6/14 22:38, Stephan Eggermont wrote:

|errors|
errors := OrderedCollection new.
SystemNavigation default allClassesDo: [ :each |
(each name beginsWith: 'ConfigurationOf' ) ifTrue: [ |list|
list := MetacelloToolBox validateConfiguration: each.
list do: [ :warning |
warning isCritical ifTrue:[errors add: each -> warning 
]]
]].
errors   an OrderedCollection(ConfigurationOf->Error: No usable baseline or versions defined. 
{ noVersionsDefined } [ #validatePragmas ] 
ConfigurationOfVersionnerTestBitmapCharacterSet->Critical Warning: The name of package 
'Collections-BitmapCharacterSet' does not match the file name ' 
Collections-BitmapCharacterSet-JAA.5' in version '1.0' { packageNameMismatch } [ 
#validateVersionSpec: ] ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The 
name of package 'VersionnerTestXML-Parser' does not match the file name 
'XML-Parser-NorbertHartl.141' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] 
ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of package 
'VersionnerTestXML-Tests-Parser' does not match the file name 'XML-Tests-Parser-JAA.14' in 
version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] 
ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified for the package 
'Collections-Support' in version '2.0.0' { noVersionSpecified } [ #validateVersionSpec: ] 
ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified for the package 
'Collections-Support' in version '2.1.0' { noVersionSpecified } [ #validateVersionSpec: ])

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sebastian Sastre]

On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano  wrote:

> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>> wrote:
>> 
>>> I think that it is possible to most if not all of the git work support into 
>>> the Smalltalk development environment ... I am doing that for GemStone with 
>>> tODE[6] and I do find myself going to the go to the command line much less 
>>> frequently ... but in tODE I have built a git merge tool and a git diff 
>>> tool ... you can get the git history of a method from the browser, etc. 
>>> 
>>> Without a relatively high degree of tool integration it can be clunky to 
>>> use git ... I am very willing to share what I've done/learned in tODE with 
>>> Pharo tool builders and of course I think Thierry Goubier has actually been 
>>> ahead of me in several different areas ...
>> 
>> That is my analysis: it works today, 'perfectly', but there is not enough 
>> tools support to make it as easy as Monticello as a whole is today.
>> 
>> If these tools exist, or we can build them quickly based Dale's code, that 
>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>> direct integration is better) that would be good.
>> 
>> Would having this change our world fundamentally ? No, IMHO
>> Is it worth the effort, is the ROI there ? I don't think so
> 
> I disagree here. I think moving our development to git will change deeply 
> (for good) our community processes and then I think it totally worths the 
> effort. 


big +1 here

The social benefit of having your code exposed in places like github outweighs 
by at an astronomical scale the current lack of amazing mergetools

If your code cannot be exposed without friction you’re done 

The noise of the jungle of 
3-new-libraries-per-day-that-can-be-installed-in-one-shot will make your work 
invisible

[Pharo-dev] spec question

[Pablo R. Digonzelli]

Hi all, two questions about Spec. 

1) How can i change the font for a ListModel or TextModel? 

2) I try , but nothing happend . I does not work but there is no error also 

l := ListModel new. 
l backgroundColorBlock: [ Color red ]. 
l openWithSpec . 

Can I change de backcolor of ListModel ? 

Sorry for my english. 

TIA 




Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Metrotec SRL 
25 de Mayo 521 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

On 26 Jun 2014, at 22:28, p...@highoctane.be wrote:

> 
> Le 26 juin 2014 21:54, "Esteban Lorenzano"  a écrit :
> >
> >
> > On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:
> >
> > > I know you, and some others, have that opinion and that is OK.
> > > I also think that it would be nice to have (better git integration).
> > >
> > > But we essentially have it today, although a bit cumbersome, awkward (cfr 
> > > https://github.com/pharo-project/pharo-core). Some of us store all their 
> > > code in git all the time.
> > >
> > > My opinion is that it is not per se the most important thing. We have to 
> > > focus on the aspects where we are better, not try being more the same as 
> > > everybody else.
> > >
> > > We need modularisation, better tools, new ways of working with live 
> > > objects, new interactive representations, mouldable tools, remote image 
> > > tools, automatic cloud deploys, magic stuff, ..
> >
> > yes… and better git integration is part of “better tools”.
> > and IMO, with the “plus” that it can boost the other areas.
> 
> Yes, Git enables all of code and assets in one single place and tooling that 
> helps a lot with changes ( e.g. gitk ). That is huge in practice.

I know that there are lots of git tools out there, but how do these help - they 
are disconnected from the image, and thus disconnected from our regular way of 
working (senders, implementors, references, ...).

The current source code format in git is cool, but can you manage a merge or 
diff like that, with all the different parts scattered over 10s, 100s of files, 
with no matter what tool ? Apart from the fact that such bigger merge is always 
very difficult, no other tools will support our world view, ever. 

https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5

You and I understand the above, no Java/C#/Go programmer will.

The next discussion will be: what are all those silly method files, why not put 
them all in one file ? Then the question is, what are all those silly 
exclamation marks in our file out format ? And so on.

I don't want to sound too negative, I just don't belief it will actually make 
that much difference.

> Phil
> 
> >
> > Esteban
> >
> > >
> > > On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:
> > >
> > >>
> > >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> > >>
> > >>>
> > >>> On 26 Jun 2014, at 19:07, Dale Henrichs 
> > >>>  wrote:
> > >>>
> >  I think that it is possible to most if not all of the git work support 
> >  into the Smalltalk development environment ... I am doing that for 
> >  GemStone with tODE[6] and I do find myself going to the go to the 
> >  command line much less frequently ... but in tODE I have built a git 
> >  merge tool and a git diff tool ... you can get the git history of a 
> >  method from the browser, etc.
> > 
> >  Without a relatively high degree of tool integration it can be clunky 
> >  to use git ... I am very willing to share what I've done/learned in 
> >  tODE with Pharo tool builders and of course I think Thierry Goubier 
> >  has actually been ahead of me in several different areas ...
> > >>>
> > >>> That is my analysis: it works today, 'perfectly', but there is not 
> > >>> enough tools support to make it as easy as Monticello as a whole is 
> > >>> today.
> > >>>
> > >>> If these tools exist, or we can build them quickly based Dale's code, 
> > >>> that would be cool (I guess its all OSProcess underneath, which I find 
> > >>> so/so, a direct integration is better) that would be good.
> > >>>
> > >>> Would having this change our world fundamentally ? No, IMHO
> > >>> Is it worth the effort, is the ROI there ? I don't think so
> > >>
> > >> I disagree here. I think moving our development to git will change 
> > >> deeply (for good) our community processes and then I think it totally 
> > >> worths the effort.
> > >> Of course, important part of the advantages came from the tools around 
> > >> git (like github) more than git itself, but all is one and the same :)
> > >> A couple of examples of what I think will improve our work:
> > >> - pull requests instead SLICES
> > >> - submodules (with different people taking care of them)
> > >> - traceability: you can map an issue with a pull requests directly 
> > >> making it a lot better to query
> > >>
> > >> Then there is other kind of advantages like:
> > >> - better entry-point for newbies to the community (they all expect 
> > >> something like git this days)
> > >> - better visibility
> > >> - confidence. This is subjective but important: companies feel more 
> > >> confident with something like git than a specific tool to keep their 
> > >> sources.
> > >> - we can stop maintaining things like smalltalkhub and important parts 
> > >> of monticello itself and concentrate our efforts in other, more 
> > >> interesting areas
> > >>
> > >> … and there are more.
> > >>
> > >> In conclusion, I think e

[Pharo-dev] Configuration critical warnings and errors in 40047

[Stephan Eggermont]

|errors|
errors := OrderedCollection new.
SystemNavigation default allClassesDo: [ :each | 
(each name beginsWith: 'ConfigurationOf' ) ifTrue: [ |list|
list := MetacelloToolBox validateConfiguration: each.
list do: [ :warning |
warning isCritical ifTrue:[errors add: each -> warning 
]]
]].
errors   an OrderedCollection(ConfigurationOf->Error: No usable baseline or 
versions defined. { noVersionsDefined } [ #validatePragmas ] 
ConfigurationOfVersionnerTestBitmapCharacterSet->Critical Warning: The name of 
package 'Collections-BitmapCharacterSet' does not match the file name ' 
Collections-BitmapCharacterSet-JAA.5' in version '1.0' { packageNameMismatch } 
[ #validateVersionSpec: ] 
ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of 
package 'VersionnerTestXML-Parser' does not match the file name 
'XML-Parser-NorbertHartl.141' in version '1.0' { packageNameMismatch } [ 
#validateVersionSpec: ] 
ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of 
package 'VersionnerTestXML-Tests-Parser' does not match the file name 
'XML-Tests-Parser-JAA.14' in version '1.0' { packageNameMismatch } [ 
#validateVersionSpec: ] ConfigurationOfVersionnerTestXMLWriter->Critical 
Warning: No version specified for the package 'Collections-Support' in version 
'2.0.0' { noVersionSpecified } [ #validateVersionSpec: ] 
ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified 
for the package 'Collections-Support' in version '2.1.0' { noVersionSpecified } 
[ #validateVersionSpec: ])

Re: [Pharo-dev] How to get started with Git and Pharo?

[p...@highoctane.be]

Le 26 juin 2014 21:54, "Esteban Lorenzano"  a écrit :
>
>
> On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:
>
> > I know you, and some others, have that opinion and that is OK.
> > I also think that it would be nice to have (better git integration).
> >
> > But we essentially have it today, although a bit cumbersome, awkward
(cfr https://github.com/pharo-project/pharo-core). Some of us store all
their code in git all the time.
> >
> > My opinion is that it is not per se the most important thing. We have
to focus on the aspects where we are better, not try being more the same as
everybody else.
> >
> > We need modularisation, better tools, new ways of working with live
objects, new interactive representations, mouldable tools, remote image
tools, automatic cloud deploys, magic stuff, ..
>
> yes… and better git integration is part of “better tools”.
> and IMO, with the “plus” that it can boost the other areas.

Yes, Git enables all of code and assets in one single place and tooling
that helps a lot with changes ( e.g. gitk ). That is huge in practice.

Phil

>
> Esteban
>
> >
> > On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:
> >
> >>
> >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> >>
> >>>
> >>> On 26 Jun 2014, at 19:07, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:
> >>>
>  I think that it is possible to most if not all of the git work
support into the Smalltalk development environment ... I am doing that for
GemStone with tODE[6] and I do find myself going to the go to the command
line much less frequently ... but in tODE I have built a git merge tool and
a git diff tool ... you can get the git history of a method from the
browser, etc.
> 
>  Without a relatively high degree of tool integration it can be
clunky to use git ... I am very willing to share what I've done/learned in
tODE with Pharo tool builders and of course I think Thierry Goubier has
actually been ahead of me in several different areas ...
> >>>
> >>> That is my analysis: it works today, 'perfectly', but there is not
enough tools support to make it as easy as Monticello as a whole is today.
> >>>
> >>> If these tools exist, or we can build them quickly based Dale's code,
that would be cool (I guess its all OSProcess underneath, which I find
so/so, a direct integration is better) that would be good.
> >>>
> >>> Would having this change our world fundamentally ? No, IMHO
> >>> Is it worth the effort, is the ROI there ? I don't think so
> >>
> >> I disagree here. I think moving our development to git will change
deeply (for good) our community processes and then I think it totally
worths the effort.
> >> Of course, important part of the advantages came from the tools around
git (like github) more than git itself, but all is one and the same :)
> >> A couple of examples of what I think will improve our work:
> >> - pull requests instead SLICES
> >> - submodules (with different people taking care of them)
> >> - traceability: you can map an issue with a pull requests directly
making it a lot better to query
> >>
> >> Then there is other kind of advantages like:
> >> - better entry-point for newbies to the community (they all expect
something like git this days)
> >> - better visibility
> >> - confidence. This is subjective but important: companies feel more
confident with something like git than a specific tool to keep their
sources.
> >> - we can stop maintaining things like smalltalkhub and important parts
of monticello itself and concentrate our efforts in other, more interesting
areas
> >>
> >> … and there are more.
> >>
> >> In conclusion, I think expending time in git integration is one of the
best ways to contribute to the develop of Pharo nowadays.
> >>
> >> Esteban
> >>
> >>>
> >>> Anyway, it is a delicate subject as it also touches on the
representation of the file format.
> >
> >
>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[Esteban Lorenzano]

On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:

> I know you, and some others, have that opinion and that is OK.
> I also think that it would be nice to have (better git integration).
> 
> But we essentially have it today, although a bit cumbersome, awkward (cfr 
> https://github.com/pharo-project/pharo-core). Some of us store all their code 
> in git all the time.
> 
> My opinion is that it is not per se the most important thing. We have to 
> focus on the aspects where we are better, not try being more the same as 
> everybody else.
> 
> We need modularisation, better tools, new ways of working with live objects, 
> new interactive representations, mouldable tools, remote image tools, 
> automatic cloud deploys, magic stuff, ..

yes… and better git integration is part of “better tools”. 
and IMO, with the “plus” that it can boost the other areas.

Esteban  

> 
> On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:
> 
>> 
>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>>> wrote:
>>> 
 I think that it is possible to most if not all of the git work support 
 into the Smalltalk development environment ... I am doing that for 
 GemStone with tODE[6] and I do find myself going to the go to the command 
 line much less frequently ... but in tODE I have built a git merge tool 
 and a git diff tool ... you can get the git history of a method from the 
 browser, etc. 
 
 Without a relatively high degree of tool integration it can be clunky to 
 use git ... I am very willing to share what I've done/learned in tODE with 
 Pharo tool builders and of course I think Thierry Goubier has actually 
 been ahead of me in several different areas ...
>>> 
>>> That is my analysis: it works today, 'perfectly', but there is not enough 
>>> tools support to make it as easy as Monticello as a whole is today.
>>> 
>>> If these tools exist, or we can build them quickly based Dale's code, that 
>>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>>> direct integration is better) that would be good.
>>> 
>>> Would having this change our world fundamentally ? No, IMHO
>>> Is it worth the effort, is the ROI there ? I don't think so
>> 
>> I disagree here. I think moving our development to git will change deeply 
>> (for good) our community processes and then I think it totally worths the 
>> effort. 
>> Of course, important part of the advantages came from the tools around git 
>> (like github) more than git itself, but all is one and the same :)
>> A couple of examples of what I think will improve our work: 
>> - pull requests instead SLICES 
>> - submodules (with different people taking care of them)
>> - traceability: you can map an issue with a pull requests directly making it 
>> a lot better to query
>> 
>> Then there is other kind of advantages like: 
>> - better entry-point for newbies to the community (they all expect something 
>> like git this days)
>> - better visibility 
>> - confidence. This is subjective but important: companies feel more 
>> confident with something like git than a specific tool to keep their 
>> sources. 
>> - we can stop maintaining things like smalltalkhub and important parts of 
>> monticello itself and concentrate our efforts in other, more interesting 
>> areas
>> 
>> … and there are more. 
>> 
>> In conclusion, I think expending time in git integration is one of the best 
>> ways to contribute to the develop of Pharo nowadays.
>> 
>> Esteban
>> 
>>> 
>>> Anyway, it is a delicate subject as it also touches on the representation 
>>> of the file format.
> 
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

I know you, and some others, have that opinion and that is OK.
I also think that it would be nice to have (better git integration).

But we essentially have it today, although a bit cumbersome, awkward (cfr 
https://github.com/pharo-project/pharo-core). Some of us store all their code 
in git all the time.

My opinion is that it is not per se the most important thing. We have to focus 
on the aspects where we are better, not try being more the same as everybody 
else.

We need modularisation, better tools, new ways of working with live objects, 
new interactive representations, mouldable tools, remote image tools, automatic 
cloud deploys, magic stuff, ..
 
On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:

> 
> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>> wrote:
>> 
>>> I think that it is possible to most if not all of the git work support into 
>>> the Smalltalk development environment ... I am doing that for GemStone with 
>>> tODE[6] and I do find myself going to the go to the command line much less 
>>> frequently ... but in tODE I have built a git merge tool and a git diff 
>>> tool ... you can get the git history of a method from the browser, etc. 
>>> 
>>> Without a relatively high degree of tool integration it can be clunky to 
>>> use git ... I am very willing to share what I've done/learned in tODE with 
>>> Pharo tool builders and of course I think Thierry Goubier has actually been 
>>> ahead of me in several different areas ...
>> 
>> That is my analysis: it works today, 'perfectly', but there is not enough 
>> tools support to make it as easy as Monticello as a whole is today.
>> 
>> If these tools exist, or we can build them quickly based Dale's code, that 
>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>> direct integration is better) that would be good.
>> 
>> Would having this change our world fundamentally ? No, IMHO
>> Is it worth the effort, is the ROI there ? I don't think so
> 
> I disagree here. I think moving our development to git will change deeply 
> (for good) our community processes and then I think it totally worths the 
> effort. 
> Of course, important part of the advantages came from the tools around git 
> (like github) more than git itself, but all is one and the same :)
> A couple of examples of what I think will improve our work: 
> - pull requests instead SLICES 
> - submodules (with different people taking care of them)
> - traceability: you can map an issue with a pull requests directly making it 
> a lot better to query
> 
> Then there is other kind of advantages like: 
> - better entry-point for newbies to the community (they all expect something 
> like git this days)
> - better visibility 
> - confidence. This is subjective but important: companies feel more confident 
> with something like git than a specific tool to keep their sources. 
> - we can stop maintaining things like smalltalkhub and important parts of 
> monticello itself and concentrate our efforts in other, more interesting areas
> 
> … and there are more. 
> 
> In conclusion, I think expending time in git integration is one of the best 
> ways to contribute to the develop of Pharo nowadays.
> 
> Esteban
> 
>> 
>> Anyway, it is a delicate subject as it also touches on the representation of 
>> the file format.

Re: [Pharo-dev] about ~=

[p...@highoctane.be]

Couldn't we just have an expression evaluator done with PetitParser doing
these things?

Tcl and Bash have this expr: thing.


(Expression parse: '5+3*2') value.
(Expression parse: ':a | 5+:a*2') value:10.
(Expression parse: ':a | 5+:a*2') value:self x.

With the thesis of Lukas Renggli these was this Helvetia story.
Is there any chance we see something around these lines now that there is a
new compiler thing inside Pharo?

So:

someMethod: anX

^ 5 + anX * 2

Phil





On Thu, Jun 26, 2014 at 6:11 PM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> Esteban A. Maringolo wrote
> > If one thing confuses people in that realm is non arithmetic precedence:
> > Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.
> >
> > And we're not going to change that either. It's not worthy, and I
> > doubt if it is possible at all.
>
> I'm probably late to the party with this reply. The primary reason for not
> changing this is that it would be incorrect. It comes down to intrinsic
> versus extrinsic meaning. A multiple operator has an intrinsic meaning: it
> means multiple. But a message name does not have intrinsic meaning (other
> than it is a good idea to have the name represent what it does). The
> meaning
> of a message is determined by the receiver. e.g. if PetitParser defines #*
> to mean "0 or more repetitions", what happens when someone has decided that
> it should be evaluated before #+?
>
> Message sending precedence can only be defined in terms of the type of
> message: unary, binary (or infix), and keyword, since the interpretation of
> the message is the receiver's responsibility, not the compiler's.
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/about-tp4764892p4765070.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban Lorenzano]

On 26 Jun 2014, at 15:39, Hernán Morales Durand  
wrote:

> 
> 2014-06-26 10:09 GMT-03:00 Esteban Lorenzano :
> you are basically creating 1000 * 10 morphs (and complex ones). 
> 
> Actually, I want to create about 20 million of rows.
>  
> I would just do a matrix morph with just one morph and rendering the matrix 
> in the canvas (overriding the #drawOn:)
> 
> 
> Yes, that seems to be the path.
>  
> BTW, I do not think VW would work like that either: IMO, that design 
> (pre-generating the cells)  is bad and it never works. 
> Other frameworks use a datasource design (like cocoa, swt… and basically all 
> the serious frameworks I know about).
> and no, we do not have a default design for this kind of big components (a 
> serious absence, IMO).
> 
> 
> Do you have an example of those frameworks displaying millions of rows? How 
> they manage scrolling?
> Thanks for the tips.

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSTableView_Class/Reference/Reference.html
(and around)

now… how it is implemented, I always take cocotron project 
(http://www.cocotron.org) as an inspiration (even if in ObjC, you can take a 
lot of ideas from there)

Esteban

> 
> Hernán
> 

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban A. Maringolo]

2014-06-26 15:39 GMT-03:00 Hernán Morales Durand :
> 2014-06-26 10:09 GMT-03:00 Esteban Lorenzano :
>
>> you are basically creating 1000 * 10 morphs (and complex ones).
> Actually, I want to create about 20 million of rows.

Cool :)

> Do you have an example of those frameworks displaying millions of rows? How
> they manage scrolling?

They recycle the views, showing only views for the items that fit on
screen and, maybe, a few extra at the edges. Using callbacks to get
the view and bind the data for each one.

There was a way to use Dolphin Smalltalk ListView to use its
underlying SysListView32 in virtual mode (I can't find it now).
There are HTML list widgets that also do that. Here is a case of how
to it with C# 
Of course nothing of this helps you immediately, unless you're going
to implement such virtual/recycling lists in Morph.

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] How to get started with Git and Pharo?

[Esteban Lorenzano]

On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:

> 
> On 26 Jun 2014, at 19:07, Dale Henrichs  
> wrote:
> 
>> I think that it is possible to most if not all of the git work support into 
>> the Smalltalk development environment ... I am doing that for GemStone with 
>> tODE[6] and I do find myself going to the go to the command line much less 
>> frequently ... but in tODE I have built a git merge tool and a git diff tool 
>> ... you can get the git history of a method from the browser, etc. 
>> 
>> Without a relatively high degree of tool integration it can be clunky to use 
>> git ... I am very willing to share what I've done/learned in tODE with Pharo 
>> tool builders and of course I think Thierry Goubier has actually been ahead 
>> of me in several different areas ...
> 
> That is my analysis: it works today, 'perfectly', but there is not enough 
> tools support to make it as easy as Monticello as a whole is today.
> 
> If these tools exist, or we can build them quickly based Dale's code, that 
> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
> direct integration is better) that would be good.
> 
> Would having this change our world fundamentally ? No, IMHO
> Is it worth the effort, is the ROI there ? I don't think so

I disagree here. I think moving our development to git will change deeply (for 
good) our community processes and then I think it totally worths the effort. 
Of course, important part of the advantages came from the tools around git 
(like github) more than git itself, but all is one and the same :)
A couple of examples of what I think will improve our work: 
- pull requests instead SLICES 
- submodules (with different people taking care of them)
- traceability: you can map an issue with a pull requests directly making it a 
lot better to query

Then there is other kind of advantages like: 
- better entry-point for newbies to the community (they all expect something 
like git this days)
- better visibility 
- confidence. This is subjective but important: companies feel more confident 
with something like git than a specific tool to keep their sources. 
- we can stop maintaining things like smalltalkhub and important parts of 
monticello itself and concentrate our efforts in other, more interesting areas

… and there are more. 

In conclusion, I think expending time in git integration is one of the best 
ways to contribute to the develop of Pharo nowadays.

Esteban

> 
> Anyway, it is a delicate subject as it also touches on the representation of 
> the file format.
> 
> 

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban A. Maringolo]

2014-06-26 15:13 GMT-03:00 Esteban A. Maringolo :
> 2014-06-26 13:39 GMT-03:00 stepharo :
>
 Other frameworks use a datasource design (like cocoa, swt… and basically
 all the serious frameworks I know about).
>> can you give a pointer?

> ps: There is a forthcoming RecyclerView in the next Android SDK. It is
> being announced in this very moment in Google I/O, Room 8.

http://developer.android.com/intl/es/preview/material/ui-widgets.html#recyclerview



Esteban A. Maringolo

Re: [Pharo-dev] evicted zombie process from run queue

[Hernán Morales Durand]

2014-06-26 10:09 GMT-03:00 Esteban Lorenzano :

> you are basically creating 1000 * 10 morphs (and complex ones).
>

Actually, I want to create about 20 million of rows.


> I would just do a matrix morph with just one morph and rendering the
> matrix in the canvas (overriding the #drawOn:)
>
>
Yes, that seems to be the path.


> BTW, I do not think VW would work like that either: IMO, that design
> (pre-generating the cells)  is bad and it never works.
> Other frameworks use a datasource design (like cocoa, swt… and basically
> all the serious frameworks I know about).
> and no, we do not have a default design for this kind of big components (a
> serious absence, IMO).
>
>
Do you have an example of those frameworks displaying millions of rows? How
they manage scrolling?
Thanks for the tips.

Hernán

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

[Tudor Girba]

I like these names.

Doru


On Thu, Jun 26, 2014 at 4:38 PM, Marcus Denker 
wrote:

>
> On 25 Jun 2014, at 14:06, Marcus Denker  wrote:
>
> Hi,
>
> Already in Pharo3 all instance variables are described using meta-objects
> (so called slots).
>
> To make it easier to access the slots, I added some simple methods to
> ClassDescription on 4.0 043,
> Now we can do e.g.:
>
> Context slots
> Context allSlots
>
> Point hasSlotNamed: #x
> Point slotNamed: #x
>
>
> As Camille noted, we need a different API on the Objects to read and write
> slots.
>
> We came up with:
>
> #readSlot:
> #readSlotNamed:
> #writeSlot:value:
> #writeSlotNamed:value:
> #writeToSlot:of:(this is what the compiler generates to
> reflectively write a slot)
>
> e.g.
>
> 5@3 readSlot: (Point slotNamed: #x)
> 5@3 writeSlotNamed: #x value: 7
>
>
> This is in the issue tracker:
> https://pharo.fogbugz.com/f/cases/13418/reflective-API-for-Slots-on-Object
>
> Marcus
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban A. Maringolo]

2014-06-26 13:39 GMT-03:00 stepharo :

>>> Other frameworks use a datasource design (like cocoa, swt… and basically
>>> all the serious frameworks I know about).
> can you give a pointer?

You're asking the other Esteban, but I can share how Android does it,
by using AdapterView and Adapter.

http://developer.android.com/intl/es/reference/android/widget/AdapterView.html

http://developer.android.com/intl/es/reference/android/widget/Adapter.html

In the case of Lists there is ListView with specific list behavior,
but the recycling is the same.

Regards,


Esteban A. Maringolo

ps: There is a forthcoming RecyclerView in the next Android SDK. It is
being announced in this very moment in Google I/O, Room 8.

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

On 26 Jun 2014, at 19:07, Dale Henrichs  
wrote:

> I think that it is possible to most if not all of the git work support into 
> the Smalltalk development environment ... I am doing that for GemStone with 
> tODE[6] and I do find myself going to the go to the command line much less 
> frequently ... but in tODE I have built a git merge tool and a git diff tool 
> ... you can get the git history of a method from the browser, etc. 
> 
> Without a relatively high degree of tool integration it can be clunky to use 
> git ... I am very willing to share what I've done/learned in tODE with Pharo 
> tool builders and of course I think Thierry Goubier has actually been ahead 
> of me in several different areas ...

That is my analysis: it works today, 'perfectly', but there is not enough tools 
support to make it as easy as Monticello as a whole is today.

If these tools exist, or we can build them quickly based Dale's code, that 
would be cool (I guess its all OSProcess underneath, which I find so/so, a 
direct integration is better) that would be good.

Would having this change our world fundamentally ? No, IMHO
Is it worth the effort, is the ROI there ? I don't think so

Anyway, it is a delicate subject as it also touches on the representation of 
the file format.

Re: [Pharo-dev] How to get started with Git and Pharo?

[p...@highoctane.be]

Stef,

You need to cut your teeth for a decent couple hours to get to terms with
Git.
Especially when using a workflow with branches, with merges, and several
contributors.
I knew of quite a couple of SCMs (including Hg) but Git is a special beast.

I liked Git Recipes: A Problem Solution Approach as it was very pragmatic.

HTH
Phil


On Thu, Jun 26, 2014 at 7:09 PM, stepharo  wrote:

> I read
>
> http://www.stic.st/wp-content/conferences/2012/Wednesday/
> 1415-Practical_Git_for_Smalltalk-Henrichs.pdf
> and I found
> http://forum.world.st/Pharo-git-td4693999.html
>
> But is there something that works and it simple?
>
> Stef
>
>
> On 26/6/14 18:27, stepharo wrote:
>
>> Hi
>>
>> I do not know the dif between git file tree, file tree and I would
>> like to know how to get
>> started with git in Pharo?
>>
>> What should I read?
>>
>> Stef
>>
>
>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[Yuriy Tymchuk]

I can only suggest you to read my blogpost about configurations and versioning: 
http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html

I usually mix filetree and gitfiletree. Last one is better, because you don’t 
have to remember to commit in git each time you commit in pharo.
(Also I think that gitfiletree is not working with Pharo4)

Uko

On 26 Jun 2014, at 18:27, stepharo  wrote:

> Hi
> 
> I do not know the dif between git file tree, file tree and I would like 
> to know how to get
> started with git in Pharo?
> 
> What should I read?
> 
> Stef
> 

Re: [Pharo-dev] about ~=

[Esteban A. Maringolo]

2014-06-26 13:11 GMT-03:00 Richard Sargent :
> Esteban A. Maringolo wrote
>> If one thing confuses people in that realm is non arithmetic precedence:
>> Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.
>>
>> And we're not going to change that either. It's not worthy, and I
>> doubt if it is possible at all.
>
> I'm probably late to the party with this reply. The primary reason for not
> changing this is that it would be incorrect. It comes down to intrinsic
> versus extrinsic meaning. A multiple operator has an intrinsic meaning: it
> means multiple. But a message name does not have intrinsic meaning (other
> than it is a good idea to have the name represent what it does). The meaning
> of a message is determined by the receiver. e.g. if PetitParser defines #*
> to mean "0 or more repetitions", what happens when someone has decided that
> it should be evaluated before #+?

That's exactly why I said it is not worth it. When the expression is
with numeric literals is one thing, as soon as you're using variables
it is something different.

What I meant is changing #~= is as fanciful as doing that.

> Message sending precedence can only be defined in terms of the type of
> message: unary, binary (or infix), and keyword, since the interpretation of
> the message is the receiver's responsibility, not the compiler's.

That's why I said I doubt if it is feasible.



Esteban A. Maringolo

Re: [Pharo-dev] How to get started with Git and Pharo?

[stepharo]

I read

http://www.stic.st/wp-content/conferences/2012/Wednesday/1415-Practical_Git_for_Smalltalk-Henrichs.pdf
and I found
http://forum.world.st/Pharo-git-td4693999.html

But is there something that works and it simple?

Stef


On 26/6/14 18:27, stepharo wrote:

Hi

I do not know the dif between git file tree, file tree and I would 
like to know how to get

started with git in Pharo?

What should I read?

Stef

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

Stef,

My introduction to git came largely from reading "A successful Git
branching model"[1]. I tried to think how to map this particular git work
flow to Metacello and long story short, decided to adapt Metacello to git:)

It is also probably worth reading "What is a good Git workflow?"[2]. This
article is more about how to use GitHub, but frankly the appeal of git to
me goes hand in hand with a good collaboration model and GitHub does a good
job supporting that.

The first time you read these articles don't pay attention to the details,
but try to get the overall flow/functionality and try to draw parallels to
the work the you do with Monticello and Metacello ... let the thoughts
marinate, ask some questions.

"Pro Git"[3] is a book/web site and would recommend that you take a run
through Chapter 2[4] to get a taste of git in action at the command line
and virtually everything that you need to know to work on your own with git
is covered in this chapter. Chapter 3[5] is on the nitty gritty of
branching ... but again at this stage you want to just skim through the
docs and get a feel of what is possible ... if something doesn't make sense
at this stage ...
ignore it:)

Now go back to the  "What is a good Git workflow?"[2] paper and read it in
detail ... if you see a command/operation that you don't understand google
it or look it up in "Pro Git" or ask questions ...

Basically I am recommending that for your first foray into Git and
Smalltalk you will be trying to follow the  "What is a good Git
workflow?"[2] model.

FileTree allows you save Monticello packages into a git repository, but
with FileTree you have to do all of the git commands from the command line.

I'll let Thierry Goubier describe GitFileTree because I think it that
package does a bit of remote control 

I think that it is possible to most if not all of the git work support into
the Smalltalk development environment ... I am doing that for GemStone with
tODE[6] and I do find myself going to the go to the command line much less
frequently ... but in tODE I have built a git merge tool and a git diff
tool ... you can get the git history of a method from the browser, etc.

Without a relatively high degree of tool integration it can be clunky to
use git ... I am very willing to share what I've done/learned in tODE with
Pharo tool builders and of course I think Thierry Goubier has actually been
ahead of me in several different areas ...

Of course there are other git workflows out there and other git
collaboration sites besides GitHub...but is worth keeping things simple at
first (I think) and when you have mastered git/github basics both
personally and from a tool level, then it is a perfectly good time to start
looking at other workflows and tools, because then you are able to make
informed judgements ...

HTH,

Dale

[1] http://nvie.com/posts/a-successful-git-branching-model/
[2] https://help.github.com/articles/what-is-a-good-git-workflow
[3] http://git-scm.com/book
[4] http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository
[5] http://git-scm.com/book/en/Git-Branching
[6] https://github.com/dalehenrich/tode


On Thu, Jun 26, 2014 at 9:27 AM, stepharo  wrote:

> Hi
>
> I do not know the dif between git file tree, file tree and I would
> like to know how to get
> started with git in Pharo?
>
> What should I read?
>
> Stef
>
>

Re: [Pharo-dev] about ~=

[kilon alios]

lol :D


On Thu, Jun 26, 2014 at 8:03 PM, Norbert Hartl  wrote:

>
>
> Am 26.06.2014 um 12:46 schrieb Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com>:
>
> $! is not classified as a binary character right now, is it?
> Of course it's possible but I'd just say why this particular symbol?
> It does not look mathematical either. Or do you love C/C++ so much?
>
> Note that ~= has same meaning in Matlab.
>
> There are other possibilities like /=  or <> (Fortran 95, ADA), even the
> long form =/=.
>
> But frankly, I don't buy this kind of change, for the sake of looking like
> some {} language, making such a deep change is overkill.
>
> In any case, a big -1 for !=
>
>
> +1 ... hmmm err... I mean -1...hmmm ok +1 for the -1. Ok, I guess I suck
> at math.
>
> Norbert
>
>
> 2014-06-26 10:47 GMT+02:00 Max Leske :
>
>>
>> On 26.06.2014, at 10:15, Christophe Demarey 
>> wrote:
>>
>> > Hi,
>> >
>> > I would like to make a suggestion that may lead to a long debate but
>> let's go: What do you think about deprecating ~= and replace it with != for
>> example?
>> > Why? In mathematics the symbol ~ is used for equivalence. To me (and I
>> think any newcomer to Smalltalk) the first guess of the meaning of ~= is
>> equivalent to => missed. The meaning is totally different: "Answer whether
>> the receiver and the argument do not represent the same object.”
>>
>> +1
>> But then I also want to suggest #!== for negating identity.
>>
>> >
>> > I never used this method because it is too confusing for me. I prefer
>> to use (a = b) not or (a = b) ifFalse:.
>> > So, the discussion is open ...
>> >
>> > Christophe
>>
>>
>>
>

Re: [Pharo-dev] about ~=

[Norbert Hartl]

> Am 26.06.2014 um 12:46 schrieb Nicolas Cellier 
> :
> 
> $! is not classified as a binary character right now, is it?
> Of course it's possible but I'd just say why this particular symbol?
> It does not look mathematical either. Or do you love C/C++ so much?
> 
> Note that ~= has same meaning in Matlab.
> 
> There are other possibilities like /=  or <> (Fortran 95, ADA), even the long 
> form =/=.
> 
> But frankly, I don't buy this kind of change, for the sake of looking like 
> some {} language, making such a deep change is overkill.
> 
> In any case, a big -1 for != 

+1 ... hmmm err... I mean -1...hmmm ok +1 for the -1. Ok, I guess I suck at 
math.

Norbert
> 
> 2014-06-26 10:47 GMT+02:00 Max Leske :
>> 
>> On 26.06.2014, at 10:15, Christophe Demarey  
>> wrote:
>> 
>> > Hi,
>> >
>> > I would like to make a suggestion that may lead to a long debate but let's 
>> > go: What do you think about deprecating ~= and replace it with != for 
>> > example?
>> > Why? In mathematics the symbol ~ is used for equivalence. To me (and I 
>> > think any newcomer to Smalltalk) the first guess of the meaning of ~= is 
>> > equivalent to => missed. The meaning is totally different: "Answer whether 
>> > the receiver and the argument do not represent the same object.”
>> 
>> +1
>> But then I also want to suggest #!== for negating identity.
>> 
>> >
>> > I never used this method because it is too confusing for me. I prefer to 
>> > use (a = b) not or (a = b) ifFalse:.
>> > So, the discussion is open ...
>> >
>> > Christophe
> 

Re: [Pharo-dev] super initialize

[Norbert Hartl]

> Am 26.06.2014 um 18:48 schrieb stepharo :
> 
> 
>> When you create a new instance with #new automatically
>> #initialize is sent.
>> 
>> The default #initialize is provided in ProtoObject at
>> the highest level of the class hierarchy (doing nothing).
>> 
>> If you look deeper in the hierarchy you will notice that
>> 
>>  - some subclasses of Object override the #initialize
>>method and call "super initialize"
>>  - some subclasses of Object override the #initialize
>>method without calling "super initialize"
>> 
>> No problem at the moment as there is no initialization
>> done in Object or ProtoObject at the current point in
>> time.
>> 
>> But the question is should we care if there may be
>> in the future?
> I prefer to have a super call for consistency reasons. Igor jokes me usually 
> on that.
I'm on your side. Screw Igor :)

Norbert
> Now there should not be an initialize in ProtoObject and Object in the future.
> 
> So which ones
> 
> - some subclasses of Object override the #initialize
>   method without calling "super initialize"
> 
> 
> 
> Stef
>> 
>> Thx
>> T.
> 
> 

Re: [Pharo-dev] super initialize

[stepharo]

When you create a new instance with #new automatically
#initialize is sent.

The default #initialize is provided in ProtoObject at
the highest level of the class hierarchy (doing nothing).

If you look deeper in the hierarchy you will notice that

  - some subclasses of Object override the #initialize
method and call "super initialize"
  - some subclasses of Object override the #initialize
method without calling "super initialize"

No problem at the moment as there is no initialization
done in Object or ProtoObject at the current point in
time.

But the question is should we care if there may be
in the future?
I prefer to have a super call for consistency reasons. Igor jokes me 
usually on that.
Now there should not be an initialize in ProtoObject and Object in the 
future.


So which ones

 - some subclasses of Object override the #initialize
   method without calling "super initialize"



Stef


Thx
T.

Re: [Pharo-dev] Pharo and Amber relationship

[stepharo]

On 26/6/14 10:10, Torsten Bergmann wrote:

Hi,

as I read somewhere that Amber want to stay compatible
with Pharo

it is important.


(at least with the core classes) I wonder
how this compatibility is measured/enforced these days.

Difficult.


Are there tools to exchange code between the two?

I also wonder if what would be necessary to run Amber on
Java Nashorn (a JS engine that comes with the JDK 8).
Could serve as a horse to also run on JVM...

May be we should stop developing in our lovely language and jump in JS.
It would solve many problems and open a lot more.
But seriously after the Java wave



Why I'm asking: I think one of our goals should be to
make Pharo more widely usable to not end up as an island.

We daily try to improve our system but this is not easy.



If Pharo and Amber stay compatible to a certain amount
Amber could open the door for Pharo to other target platforms
(browser, mobile devices, other language runtimes) as
JS is available nearly everywhere.

Running Pharo on JS VM would be interesting too.

Stef

Re: [Pharo-dev] evicted zombie process from run queue

[stepharo]

Esteban wrote:

Other frameworks use a datasource design (like cocoa, swt… and basically all 
the serious frameworks I know about).


can you give a pointer?


and no, we do not have a default design for this kind of big components (a 
serious absence, IMO).

Serious absence indeed.

Stephan

Re: [Pharo-dev] about ~=

[stepharo]

;)


On 26/6/14 12:46, Nicolas Cellier wrote:

$! is not classified as a binary character right now, is it?
Of course it's possible but I'd just say why this particular symbol?
It does not look mathematical either. Or do you love C/C++ so much?

Note that ~= has same meaning in Matlab.

There are other possibilities like /=  or <> (Fortran 95, ADA), even 
the long form =/=.


But frankly, I don't buy this kind of change, for the sake of looking 
like some {} language, making such a deep change is overkill.


In any case, a big -1 for !=

[Pharo-dev] How to get started with Git and Pharo?

[stepharo]

Hi

I do not know the dif between git file tree, file tree and I would 
like to know how to get

started with git in Pharo?

What should I read?

Stef

Re: [Pharo-dev] about ~=

[Richard Sargent]

Esteban A. Maringolo wrote
> If one thing confuses people in that realm is non arithmetic precedence:
> Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.
> 
> And we're not going to change that either. It's not worthy, and I
> doubt if it is possible at all.

I'm probably late to the party with this reply. The primary reason for not
changing this is that it would be incorrect. It comes down to intrinsic
versus extrinsic meaning. A multiple operator has an intrinsic meaning: it
means multiple. But a message name does not have intrinsic meaning (other
than it is a good idea to have the name represent what it does). The meaning
of a message is determined by the receiver. e.g. if PetitParser defines #*
to mean "0 or more repetitions", what happens when someone has decided that
it should be evaluated before #+?

Message sending precedence can only be defined in terms of the type of
message: unary, binary (or infix), and keyword, since the interpretation of
the message is the receiver's responsibility, not the compiler's.




--
View this message in context: http://forum.world.st/about-tp4764892p4765070.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [pharo-project/pharo-core] a4c40a: 40047

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5
  
https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5
  Author: Jenkins Build Server 
  Date:   2014-06-26 (Thu, 26 Jun 2014)

  Changed paths:
A Kernel.package/Object.class/instance/introspection/readSlotNamed_.st
A Kernel.package/Object.class/instance/introspection/readSlot_.st
A 
Kernel.package/Object.class/instance/introspection/writeSlotNamed_value_.st
A Kernel.package/Object.class/instance/introspection/writeSlot_value_.st
A Kernel.package/Object.class/instance/introspection/writeToSlot_of_.st
A KernelTests.package/ObjectTest.class/instance/tests - 
introspection/testReadSlot.st
A KernelTests.package/ObjectTest.class/instance/tests - 
introspection/testReadSlotNamed.st
A KernelTests.package/ObjectTest.class/instance/tests - 
introspection/testWriteSlotNamedValue.st
A KernelTests.package/ObjectTest.class/instance/tests - 
introspection/testWriteSlotValue.st
A KernelTests.package/ObjectTest.class/instance/tests - 
introspection/testWriteToSlotOf.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script47.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40047.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Slot.package/InstanceVariableSlot.class/class/cleanup/resetIvarSlots.st
M Slot.package/Slot.class/instance/meta-object-protocol/write_to_.st
M Slot.package/Slot.class/instance/private/internalWrite_to_.st

  Log Message:
  ---
  40047
13412 add Helper: resetIvarSlots
https://pharo.fogbugz.com/f/cases/13412

13414 Keyboard shortcuts in Nautilus stopped working
https://pharo.fogbugz.com/f/cases/13414

13418 reflective API for Slots on Object
https://pharo.fogbugz.com/f/cases/13418

http://files.pharo.org/image/40/40047.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40047
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

[Marcus Denker]

On 25 Jun 2014, at 14:06, Marcus Denker  wrote:

> Hi,
> 
> Already in Pharo3 all instance variables are described using meta-objects (so 
> called slots).
> 
> To make it easier to access the slots, I added some simple methods to 
> ClassDescription on 4.0 043,
> Now we can do e.g.:
> 
> Context slots 
> Context allSlots
> 
> Point hasSlotNamed: #x
> Point slotNamed: #x
> 

As Camille noted, we need a different API on the Objects to read and write 
slots.

We came up with:

#readSlot:
#readSlotNamed:
#writeSlot:value:
#writeSlotNamed:value:
#writeToSlot:of:(this is what the compiler generates to 
reflectively write a slot)

e.g.

5@3 readSlot: (Point slotNamed: #x)
5@3 writeSlotNamed: #x value: 7


This is in the issue tracker: 
https://pharo.fogbugz.com/f/cases/13418/reflective-API-for-Slots-on-Object

Marcus

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Johan Brichau]

Nicolai,

It's not a public configuration and it loads quite some packages.
I will pick up this issue this evening to get a better reproducible case.

thx
Johan

On 26 Jun 2014, at 16:03, Nicolai Hess  wrote:

> 2014-06-26 15:37 GMT+02:00 Goubier Thierry :
> 
> 
> Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
> 
> 
> On 26 Jun 2014, at 15:17, Johan Brichau  wrote:
> 
> I will do that, but the main problem is not the loading speed.
> The real problem is that the image blows up (i.e. crashes) when a browser is 
> open because it runs out of memory.
> 
> But yes, I will make a ticket and get some more profiling with that so we can 
> fix it.
> Right now, I have to tell my co-workers to close all browsers when they do a 
> full code load interactively... it works but it's a bit ridiculous ;-)
> 
> I disagree a bit ;-)
> 
> Like Thierry said before: we all expect open browsers to react to anything 
> that happens, so when you load a very large amount of code, lots of things 
> change and I can imagine the internal notifications (announcements) 
> overloading the browsers who are struggling to keep up.
> 
> This means something can be optimized in the browser... Browsers have a very 
> limited view on the underlying code, more or less a subset of a class methods 
> and their relation in higher stuff, such as the package, which means loading 
> a large body of code has little effect on the Browser (unless it's a live 
> CodeCity instance :)).
> 
> 
> Now, there is probably something wrong, and things can probably be tuned, but 
> I think this will always be slower.
> 
> Not by much.
> 
> 
> Like Stéphane said, loading a big batch of code should happen in a special 
> way, disabling updates and firing a full reset at the end - or something 
> along those lines.
> 
> I disagree with you there.
> 
> Disabling updates causes problems in many different places (RPackage, for 
> one) and correct implementation of the Browser updates should not slow it 
> down significantly. And it allow us, in the future, to have a responsive GUI 
> while loading code.
> 
> I know because after optimising it, it went from very visible to being almost 
> invisible on the profile (far below the time spent #pragma updating).
> 
> Thierry
> 
> -- 
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
> 
> 
> 
> I can not reproduce this, neither the crash nor the image memory blow up.
> I tested several ConfigurationOfXXX, with one or more open Browsers.
> 
> Can you tell me what Configuration you are trying to load and if this is a 
> fresh pharo image or
> are there any other packages loaded. 
> And do you have any Nautilus plugins enabled?
> 
> regards
> Nicolai

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Nicolai Hess]

2014-06-26 15:37 GMT+02:00 Goubier Thierry :

>
>
> Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
>
>
>> On 26 Jun 2014, at 15:17, Johan Brichau  wrote:
>>
>>  I will do that, but the main problem is not the loading speed.
>>> The real problem is that the image blows up (i.e. crashes) when a
>>> browser is open because it runs out of memory.
>>>
>>> But yes, I will make a ticket and get some more profiling with that so
>>> we can fix it.
>>> Right now, I have to tell my co-workers to close all browsers when they
>>> do a full code load interactively... it works but it's a bit ridiculous ;-)
>>>
>>
>> I disagree a bit ;-)
>>
>> Like Thierry said before: we all expect open browsers to react to
>> anything that happens, so when you load a very large amount of code, lots
>> of things change and I can imagine the internal notifications
>> (announcements) overloading the browsers who are struggling to keep up.
>>
>
> This means something can be optimized in the browser... Browsers have a
> very limited view on the underlying code, more or less a subset of a class
> methods and their relation in higher stuff, such as the package, which
> means loading a large body of code has little effect on the Browser (unless
> it's a live CodeCity instance :)).
>
>
>  Now, there is probably something wrong, and things can probably be tuned,
>> but I think this will always be slower.
>>
>
> Not by much.
>
>
>  Like Stéphane said, loading a big batch of code should happen in a
>> special way, disabling updates and firing a full reset at the end - or
>> something along those lines.
>>
>
> I disagree with you there.
>
> Disabling updates causes problems in many different places (RPackage, for
> one) and correct implementation of the Browser updates should not slow it
> down significantly. And it allow us, in the future, to have a responsive
> GUI while loading code.
>
> I know because after optimising it, it went from very visible to being
> almost invisible on the profile (far below the time spent #pragma updating).
>
> Thierry
>
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>
>

I can not reproduce this, neither the crash nor the image memory blow up.
I tested several ConfigurationOfXXX, with one or more open Browsers.

Can you tell me what Configuration you are trying to load and if this is a
fresh pharo image or
are there any other packages loaded.
And do you have any Nautilus plugins enabled?

regards
Nicolai

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Johan Brichau]

On 26 Jun 2014, at 15:25, Sven Van Caekenberghe  wrote:

> Like Stéphane said, loading a big batch of code should happen in a special 
> way, disabling updates and firing a full reset at the end - or something 
> along those lines.

If you try that in Pharo3, the RPackage structure is broken. From there on, you 
cannot do anything reasonable anymore with a package (loading, comparing, 
publishing,... )
I reported a bug in this sense, but it was flagged as invalid [1]

Johan

[1] https://pharo.fogbugz.com/default.asp?13213#102915

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Johan Brichau]

On 26 Jun 2014, at 15:25, Sven Van Caekenberghe  wrote:

> Now, there is probably something wrong, and things can probably be tuned, but 
> I think this will always be slower.

As I said, I understand it would be slower.
But an image that runs at 100% for a couple of hours and then just dies because 
it runs out of memory is not my idea of expected behavior.

Mind that the memory only gets freed when I close the browser. If I do a 
marginally smaller load, the load completes but my image size is stuck at 450 
MB until I close the open browser.

Johan

Re: [Pharo-dev] about ~=

[Esteban A. Maringolo]

2014-06-26 8:27 GMT-03:00 Sven Van Caekenberghe :
> -1 for replacing ~= with != because it is not better at all
> +1 for avoiding it altogether like you suggest
> -1 for changing ~= to mean #closeTo: I like the longer name

I adhere to keep the status quo.

If one thing confuses people in that realm is non arithmetic precedence:
Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.

And we're not going to change that either. It's not worthy, and I
doubt if it is possible at all.


You can always do (aBoolean = otherBoolean) not :)

Regards!



Esteban A. Maringolo

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban A. Maringolo]

2014-06-26 10:09 GMT-03:00 Esteban Lorenzano :
> you are basically creating 1000 * 10 morphs (and complex ones).
> I would just do a matrix morph with just one morph and rendering the matrix
> in the canvas (overriding the #drawOn:)
>
> BTW, I do not think VW would work like that either: IMO, that design
> (pre-generating the cells)  is bad and it never works.
> Other frameworks use a datasource design (like cocoa, swt… and basically all
> the serious frameworks I know about).
> and no, we do not have a default design for this kind of big components (a
> serious absence, IMO).

A recycling list/container morph would be great, and super fast.

I know... lack of manpower...  :)

Regards!

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Goubier Thierry]

Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :


On 26 Jun 2014, at 15:17, Johan Brichau  wrote:


I will do that, but the main problem is not the loading speed.
The real problem is that the image blows up (i.e. crashes) when a browser is 
open because it runs out of memory.

But yes, I will make a ticket and get some more profiling with that so we can 
fix it.
Right now, I have to tell my co-workers to close all browsers when they do a 
full code load interactively... it works but it's a bit ridiculous ;-)


I disagree a bit ;-)

Like Thierry said before: we all expect open browsers to react to anything that 
happens, so when you load a very large amount of code, lots of things change 
and I can imagine the internal notifications (announcements) overloading the 
browsers who are struggling to keep up.


This means something can be optimized in the browser... Browsers have a 
very limited view on the underlying code, more or less a subset of a 
class methods and their relation in higher stuff, such as the package, 
which means loading a large body of code has little effect on the 
Browser (unless it's a live CodeCity instance :)).



Now, there is probably something wrong, and things can probably be tuned, but I 
think this will always be slower.


Not by much.


Like Stéphane said, loading a big batch of code should happen in a special way, 
disabling updates and firing a full reset at the end - or something along those 
lines.


I disagree with you there.

Disabling updates causes problems in many different places (RPackage, 
for one) and correct implementation of the Browser updates should not 
slow it down significantly. And it allow us, in the future, to have a 
responsive GUI while loading code.


I know because after optimising it, it went from very visible to being 
almost invisible on the profile (far below the time spent #pragma updating).


Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Goubier Thierry]

Le 26/06/2014 15:17, Johan Brichau a écrit :

I will do that, but the main problem is not the loading speed.
The real problem is that the image blows up (i.e. crashes) when a browser is 
open because it runs out of memory.


Try with a simple configuration: the announcements should already be 
visible on the profile.



But yes, I will make a ticket and get some more profiling with that so we can 
fix it.
Right now, I have to tell my co-workers to close all browsers when they do a 
full code load interactively... it works but it's a bit ridiculous ;-)


Or switch to another browser :)

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Sven Van Caekenberghe]

On 26 Jun 2014, at 15:17, Johan Brichau  wrote:

> I will do that, but the main problem is not the loading speed. 
> The real problem is that the image blows up (i.e. crashes) when a browser is 
> open because it runs out of memory.
> 
> But yes, I will make a ticket and get some more profiling with that so we can 
> fix it.
> Right now, I have to tell my co-workers to close all browsers when they do a 
> full code load interactively... it works but it's a bit ridiculous ;-)

I disagree a bit ;-)

Like Thierry said before: we all expect open browsers to react to anything that 
happens, so when you load a very large amount of code, lots of things change 
and I can imagine the internal notifications (announcements) overloading the 
browsers who are struggling to keep up. 

Now, there is probably something wrong, and things can probably be tuned, but I 
think this will always be slower.

Like Stéphane said, loading a big batch of code should happen in a special way, 
disabling updates and firing a full reset at the end - or something along those 
lines. 

> cheers
> Johan
> 
> On 26 Jun 2014, at 09:47, Goubier Thierry  wrote:
> 
>> Sorry to ask then, but:
>> 
>> would it be possible to profile a configurationOf... load with and without a 
>> Nautilus open? Time spent handling announcements should be visible, and, 
>> yes, when loading code, Browsers have to be aware the code is being changed.
>> 
>> I spent some time optimizing that for AltBrowser, and it can  very 
>> significantly increase the loading time, without counting in side effects 
>> such as over-caching (and I know Nautilus does some caching, but I'm not 
>> sure I understand why).
>> 
>> Thierry
>> 
>> Le 25/06/2014 20:20, p...@highoctane.be a écrit :
>>> Maybe due to some Annoucement being picked up by Nautilus?
>>> 
>>> Phil
>>> 
>>> 
>>> 
>>> On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau >> > wrote:
>>> 
>>>   Hi,
>>> 
>>>   It seems that when even a single Nautilus system browser is open and
>>>   you do a load (using Metacello), there is a huge amount of objects
>>>   that get created and persisted in the image.
>>>   This even leads to the point that the image crashes when I try to
>>>   load our code using a ConfigurationOf. After some time, the Pharo
>>>   process is stuck at 100%, image size is over 500MB and the entire
>>>   image becomes unresponsive, finally crashing after an hour or so.
>>> 
>>>   I have not yet found which objects or why, but I just wrestled with
>>>   this all day to find out what was going on. I first thought that
>>>   Metacello was in an infinite loop but after noticing that the image
>>>   was so large (500MB) and that it got reduced to 20% of its size
>>>   after closing the browser window, I can say that Nautilus is
>>>   gathering garbage. It is definitely not Metacello because I can
>>>   trigger the same problem doing a load via Monticello only.
>>> 
>>>   When I load the ConfigurationOf without a single browser open, it
>>>   loads 5x faster and the image size stays reasonable.
>>> 
>>>   Is this a known issue? Any thoughts on what may be causing this?
>>> 
>>>   regards!
>>>   Johan
>>> 
>>> 
>> 
>> -- 
>> Thierry Goubier
>> CEA list
>> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
>> 91191 Gif sur Yvette Cedex
>> France
>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
> 
> 

Re: [Pharo-dev] evicted zombie process from run queue

[Stephan Eggermont]

Esteban wrote:
>Other frameworks use a datasource design (like cocoa, swt… and basically all 
>the serious frameworks I know about).
>and no, we do not have a default design for this kind of big components (a 
>serious absence, IMO).

Serious absence indeed.

Stephan

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

[Marcus Denker]

On 26 Jun 2014, at 15:19, Sven Van Caekenberghe  wrote:

> Thanks for taking care, these things are aways more work than expected.
> 

Indeed… and the code afterwards always looks so little and so simple ;-)

Marcus

> On 26 Jun 2014, at 15:06, Marcus Denker  wrote:
> 
>> 
>> On 25 Jun 2014, at 17:15, Marcus Denker  wrote:
>>> 
 - Opal needs to delegate code generation to the Slot.
 
>>> This is now done. Opal now, in the semantic analysis phase, annotates slot 
>>> accesses
>>> as OCSlotVariable (OCInstanceVariable we can remove later).
>>> 
>>> Then when generating, it just forwards to the slot:
>>> 
>>> emitStore: methodBuilder
>>> 
>>> slot emitStore: methodBuilder
>>> 
>> 
>> This is now finally in the image 4.0 046 
>> 
>>  Marcus
>> 
>> 
> 
> 

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

[Sven Van Caekenberghe]

Thanks for taking care, these things are aways more work than expected.

On 26 Jun 2014, at 15:06, Marcus Denker  wrote:

> 
> On 25 Jun 2014, at 17:15, Marcus Denker  wrote:
>> 
>>> - Opal needs to delegate code generation to the Slot.
>>> 
>> This is now done. Opal now, in the semantic analysis phase, annotates slot 
>> accesses
>> as OCSlotVariable (OCInstanceVariable we can remove later).
>> 
>> Then when generating, it just forwards to the slot:
>> 
>> emitStore: methodBuilder
>> 
>>  slot emitStore: methodBuilder
>> 
> 
> This is now finally in the image 4.0 046 
> 
>   Marcus
> 
> 

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Johan Brichau]

I will do that, but the main problem is not the loading speed. 
The real problem is that the image blows up (i.e. crashes) when a browser is 
open because it runs out of memory.

But yes, I will make a ticket and get some more profiling with that so we can 
fix it.
Right now, I have to tell my co-workers to close all browsers when they do a 
full code load interactively... it works but it's a bit ridiculous ;-)

cheers
Johan

On 26 Jun 2014, at 09:47, Goubier Thierry  wrote:

> Sorry to ask then, but:
> 
> would it be possible to profile a configurationOf... load with and without a 
> Nautilus open? Time spent handling announcements should be visible, and, yes, 
> when loading code, Browsers have to be aware the code is being changed.
> 
> I spent some time optimizing that for AltBrowser, and it can  very 
> significantly increase the loading time, without counting in side effects 
> such as over-caching (and I know Nautilus does some caching, but I'm not sure 
> I understand why).
> 
> Thierry
> 
> Le 25/06/2014 20:20, p...@highoctane.be a écrit :
>> Maybe due to some Annoucement being picked up by Nautilus?
>> 
>> Phil
>> 
>> 
>> 
>> On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau > > wrote:
>> 
>>Hi,
>> 
>>It seems that when even a single Nautilus system browser is open and
>>you do a load (using Metacello), there is a huge amount of objects
>>that get created and persisted in the image.
>>This even leads to the point that the image crashes when I try to
>>load our code using a ConfigurationOf. After some time, the Pharo
>>process is stuck at 100%, image size is over 500MB and the entire
>>image becomes unresponsive, finally crashing after an hour or so.
>> 
>>I have not yet found which objects or why, but I just wrestled with
>>this all day to find out what was going on. I first thought that
>>Metacello was in an infinite loop but after noticing that the image
>>was so large (500MB) and that it got reduced to 20% of its size
>>after closing the browser window, I can say that Nautilus is
>>gathering garbage. It is definitely not Metacello because I can
>>trigger the same problem doing a load via Monticello only.
>> 
>>When I load the ConfigurationOf without a single browser open, it
>>loads 5x faster and the image size stays reasonable.
>> 
>>Is this a known issue? Any thoughts on what may be causing this?
>> 
>>regards!
>>Johan
>> 
>> 
> 
> -- 
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40046
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban Lorenzano]

you are basically creating 1000 * 10 morphs (and complex ones). 
I would just do a matrix morph with just one morph and rendering the matrix in 
the canvas (overriding the #drawOn:)

BTW, I do not think VW would work like that either: IMO, that design 
(pre-generating the cells)  is bad and it never works. 
Other frameworks use a datasource design (like cocoa, swt… and basically all 
the serious frameworks I know about).
and no, we do not have a default design for this kind of big components (a 
serious absence, IMO).

Esteban

On 26 Jun 2014, at 10:00, Hernán Morales Durand  
wrote:

> Why not?
> Do you know a better grid morph? 
> 
> I have tested several ones but there is no way to visualize big matrices in 
> Pharo (I am avoiding to switch to VisualWorks for now).
> 
> Cheers,
> 
> Hernán
> 
> 
> 
> 2014-06-26 9:51 GMT-03:00 Esteban Lorenzano :
> he, you are trying to open a tree with 1000 columns and 1 rows. 
> that will never work, not like that. 
> 
> Esteban
> 
> 
> On 26 Jun 2014, at 09:45, Hernán Morales Durand  
> wrote:
> 
>> Yes, sorry I forgot that. Pharo 3.0 clean image Latest update: #30850, on 
>> Windows 8
>> The VM is the one downloaded when you do
>> 
>> $ wget -O- get.pharo.org/30+vm | bash
>> 
>> Then you open and press F2, Display version information, CogVM 4.0.0 from 
>> May 15 2014.
>> 
>> Script to reproduce it:
>> 
>> Smalltalk garbageCollect.
>> [  | matrix rows cols tree |
>> rows := 1.
>> cols := 1000.
>> matrix := Matrix rows: rows columns: cols.
>>  1 to: rows do: [ : r |  
>> 1 to: cols do: [ : c |
>> matrix at: r at: c put: SmallInteger maxVal atRandom ] ].
>> 
>> tree := TreeModel new.
>> tree columns: (
>> (1 to: cols) collect: [ : col | 
>> TreeColumnModel new
>> displayBlock: [ : node | (node content at: col) asString ];
>> headerLabel: col asString ]).
>> tree roots: ((1 to: rows) collect: [ : nrow | matrix atRow: nrow ]).
>> tree openWithSpec ] timeToRun
>> 
>> Hernán
>> 
>> 
>> 
>> 2014-06-26 2:48 GMT-03:00 stepharo :
>> Hi hernan
>> 
>> Which image?
>> What did you loaded?
>> Can you reproduce it?
>> 
>> Can someone explain what does it mean or why it happens?
>> Is that a common scenario for you?
>> 
>> I am measuring execution time for big matrices in CogVM 4.0.0. Image is 
>> unresponsive.
>> 
>> Cheers,
>> 
>> Hernán
>> 
>> 
>> 
>> 
> 
> 

[Pharo-dev] [pharo-project/pharo-core] 888b8a: 40046

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 888b8a3fd125ec2904abded3e2de62130d59deb1
  
https://github.com/pharo-project/pharo-core/commit/888b8a3fd125ec2904abded3e2de62130d59deb1
  Author: Jenkins Build Server 
  Date:   2014-06-26 (Thu, 26 Jun 2014)

  Changed paths:
A 
AST-Interpreter-Core.package/extension/InstanceVariableSlot/instance/accept_assign_inNode_.st
A 
AST-Interpreter-Core.package/extension/InstanceVariableSlot/instance/readWith_inNode_.st
A 
AST-Interpreter-Core.package/extension/OCSlotVariable/instance/accept_assign_inNode_.st
A 
AST-Interpreter-Core.package/extension/OCSlotVariable/instance/readWith_inNode_.st
A Kernel.package/ClassDescription.class/instance/slots/allSlots.st
A Kernel.package/ClassDescription.class/instance/slots/slotNamed_.st
A Kernel.package/ClassDescription.class/instance/slots/slots.st
M 
OpalCompiler-Core.package/OCClassScope.class/instance/levels/instanceScope.st
A 
OpalCompiler-Core.package/OCInstanceScope.class/instance/initializing/slots_.st
R 
OpalCompiler-Core.package/OCInstanceScope.class/instance/initializing/vars_.st
M 
OpalCompiler-Core.package/OCSemanticWarning.class/instance/accessing/compilationContext.st
A OpalCompiler-Core.package/OCSlotVariable.class/README.md
A OpalCompiler-Core.package/OCSlotVariable.class/definition.st
A OpalCompiler-Core.package/OCSlotVariable.class/instance/accessing/name.st
A OpalCompiler-Core.package/OCSlotVariable.class/instance/accessing/name_.st
A OpalCompiler-Core.package/OCSlotVariable.class/instance/accessing/slot.st
A OpalCompiler-Core.package/OCSlotVariable.class/instance/accessing/slot_.st
A 
OpalCompiler-Core.package/OCSlotVariable.class/instance/emitting/emitStore_.st
A 
OpalCompiler-Core.package/OCSlotVariable.class/instance/emitting/emitValue_.st
A 
OpalCompiler-Core.package/OCSlotVariable.class/instance/testing/isInstance.st
M 
OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/declareInstVar_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script46.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40046.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Slot.package/InstanceVariableSlot.class/instance/code 
generation/emitStore_.st
A Slot.package/InstanceVariableSlot.class/instance/code 
generation/emitValue_.st
M Slot.package/extension/Symbol/instance/asSlot.st
A 
SmartSuggestions.package/extension/OCSlotVariable/instance/specialCommands.st
R Traits.package/TClassDescription.class/instance/slots/allSlots.st
R Traits.package/TClassDescription.class/instance/slots/slotNamed_.st
R Traits.package/TClassDescription.class/instance/slots/slots.st
A Traits.package/TraitDescription.class/instance/slots/allSlots.st
A Traits.package/TraitDescription.class/instance/slots/slots.st

  Log Message:
  ---
  40046
13406 Opal should delegate code generation for Slots to the Slot meta object
https://pharo.fogbugz.com/f/cases/13406

http://files.pharo.org/image/40/40046.zip

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

[Marcus Denker]

On 25 Jun 2014, at 17:15, Marcus Denker  wrote:
> 
>> - Opal needs to delegate code generation to the Slot.
>> 
> This is now done. Opal now, in the semantic analysis phase, annotates slot 
> accesses
> as OCSlotVariable (OCInstanceVariable we can remove later).
> 
> Then when generating, it just forwards to the slot:
> 
> emitStore: methodBuilder
> 
>   slot emitStore: methodBuilder
> 

This is now finally in the image 4.0 046 

Marcus

Re: [Pharo-dev] evicted zombie process from run queue

[Hernán Morales Durand]

Why not?
Do you know a better grid morph?

I have tested several ones but there is no way to visualize big matrices in
Pharo (I am avoiding to switch to VisualWorks for now).

Cheers,

Hernán



2014-06-26 9:51 GMT-03:00 Esteban Lorenzano :

> he, you are trying to open a tree with 1000 columns and 1 rows.
> that will never work, not like that.
>
> Esteban
>
>
> On 26 Jun 2014, at 09:45, Hernán Morales Durand 
> wrote:
>
> Yes, sorry I forgot that. Pharo 3.0 clean image Latest update: #30850, on
> Windows 8
> The VM is the one downloaded when you do
>
> $ wget -O- get.pharo.org/30+vm | bash
>
> Then you open and press F2, Display version information, CogVM 4.0.0 from
> May 15 2014.
>
> Script to reproduce it:
>
> Smalltalk garbageCollect.
> [  | matrix rows cols tree |
> rows := 1.
> cols := 1000.
> matrix := Matrix rows: rows columns: cols.
>  1 to: rows do: [ : r |
> 1 to: cols do: [ : c |
> matrix at: r at: c put: SmallInteger maxVal atRandom ] ].
>
> tree := TreeModel new.
> tree columns: (
> (1 to: cols) collect: [ : col |
> TreeColumnModel new
> displayBlock: [ : node | (node content at: col) asString ];
> headerLabel: col asString ]).
> tree roots: ((1 to: rows) collect: [ : nrow | matrix atRow: nrow ]).
> tree openWithSpec ] timeToRun
>
> Hernán
>
>
>
> 2014-06-26 2:48 GMT-03:00 stepharo :
>
>> Hi hernan
>>
>> Which image?
>> What did you loaded?
>> Can you reproduce it?
>>
>>  Can someone explain what does it mean or why it happens?
>>> Is that a common scenario for you?
>>>
>>> I am measuring execution time for big matrices in CogVM 4.0.0. Image is
>>> unresponsive.
>>>
>>> Cheers,
>>>
>>> Hernán
>>>
>>>
>>
>>
>
>

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban Lorenzano]

he, you are trying to open a tree with 1000 columns and 1 rows. 
that will never work, not like that. 

Esteban

On 26 Jun 2014, at 09:45, Hernán Morales Durand  
wrote:

> Yes, sorry I forgot that. Pharo 3.0 clean image Latest update: #30850, on 
> Windows 8
> The VM is the one downloaded when you do
> 
> $ wget -O- get.pharo.org/30+vm | bash
> 
> Then you open and press F2, Display version information, CogVM 4.0.0 from May 
> 15 2014.
> 
> Script to reproduce it:
> 
> Smalltalk garbageCollect.
> [  | matrix rows cols tree |
> rows := 1.
> cols := 1000.
> matrix := Matrix rows: rows columns: cols.
>  1 to: rows do: [ : r |  
> 1 to: cols do: [ : c |
> matrix at: r at: c put: SmallInteger maxVal atRandom ] ].
> 
> tree := TreeModel new.
> tree columns: (
> (1 to: cols) collect: [ : col | 
> TreeColumnModel new
> displayBlock: [ : node | (node content at: col) asString ];
> headerLabel: col asString ]).
> tree roots: ((1 to: rows) collect: [ : nrow | matrix atRow: nrow ]).
> tree openWithSpec ] timeToRun
> 
> Hernán
> 
> 
> 
> 2014-06-26 2:48 GMT-03:00 stepharo :
> Hi hernan
> 
> Which image?
> What did you loaded?
> Can you reproduce it?
> 
> Can someone explain what does it mean or why it happens?
> Is that a common scenario for you?
> 
> I am measuring execution time for big matrices in CogVM 4.0.0. Image is 
> unresponsive.
> 
> Cheers,
> 
> Hernán
> 
> 
> 
> 

Re: [Pharo-dev] Spec, groups and version-specific packages

[Roberto Minelli]

Hi Christophe,

Thanks for the answer. I managed to do that!

Am I interpreting something wrong or the CoolBrowser-Platform itself is an 
empty package?

Cheers,
R


> 
On Jun 26, 2014, at 2:08 PM, Christophe Demarey  
wrote:

> Hi,
> 
> You can find useful information into the 'Deep into Pharo' book, chapter 9 
> (Managing projects with Metacello), section 9.12 (platform specific package).
> 
> Example:
> ConfigurationOfCoolBrowser>>baseline09: spec
> 
> spec for: #common do: [
>   spec blessing: #baseline.
>   spec repository: 'http://www.example.com/CoolBrowser'.
>   spec
>   package: 'CoolBrowser-Core';
>   package: 'CoolBrowser-Tests' with: [ spec requires: 
> 'CoolBrowser-Core' ];
>   package: 'CoolBrowser-Addons' with: [ spec requires: 
> 'CoolBrowser-Core' ];
>   package: 'CoolBrowser-AddonsTests' with: [
>   spec requires: #('CoolBrowser-Addons' 
> 'CoolBrowser-Tests' ) ].
>   spec
>   group: 'default' with: #('CoolBrowser-Core' 
> 'CoolBrowser-Addons' );
>   group: 'Core' with: #('CoolBrowser-Core' 'CoolBrowser-Platform' 
> );
>   group: 'Extras' with: #('CoolBrowser-Addon');
>   group: 'Tests' with: #('CoolBrowser-Tests' 
> 'CoolBrowser-AddonsTests' );
>   group: 'CompleteWithoutTests' with: #('Core', 'Extras' );
>   group: 'CompleteWithTests' with: #('CompleteWithoutTests', 
> 'Tests' )].
> spec for: #gemstone do: [
>   spec package: 'CoolBrowser-Platform' with: 
> 'CoolBrowser-PlatformGemstone'].
> spec for: #pharo do: [
>   spec package: 'CoolBrowser-Platform' with: 'CoolBrowser-PlatformPharo'].
> 
> Le 26 juin 2014 à 13:43, Roberto Minelli a écrit :
> 
>> Hi,
>> 
>> I have my project with my Configuration and I am using spec groups to load 
>> different sets of packages (e.g., development and user groups).
>> 
>> With the porting to Pharo 4.0 I discovered that there are some 
>> functionalities specific to Pharo 3.0 and others to Pharo 4.0, for example 
>> the fact that MethodContext is no longer part of Pharo 4.0. but it has been 
>> replaced by Context.
>> 
>> I moved such functionalities in a package, say 'MyProject-Extension30’ and 
>> Pharo 4.0 specific functionalities in 'MyProject-Extension40’.
>> 
>> Now the question is, suppose that I have a group like
>> spec group: ‘User' with: #(‘A’ ‘B’ ‘C’).
>> 
>> and another one:
>> spec group: ‘Dev' with: #(‘A’ ‘B’ ‘C’ ‘D’ ‘E’).
>> 
>> Until now, the developer (i.e., me) would do something like
>> (self project version: #bleedingEdge) load: #('Dev’)
>> 
>> and a used of my project would do
>> (self project version: #bleedingEdge) load: #(‘User’)
>> 
>> 
>> 
>> How can I factor inside the dynamic load of the two Pharo-version specific 
>> packages?
>> i.e., no matter if ‘User’ or ‘Dev’ group is loaded I need to load 
>> 'MyProject-Extension40’ if I am on Pharo 4.0 and 'MyProject-Extension30’ if 
>> on Pharo 3.0.
>> 
>> Thanks for your help,
>> Roberto
> 

Re: [Pharo-dev] evicted zombie process from run queue

[Hernán Morales Durand]

Yes, sorry I forgot that. Pharo 3.0 clean image Latest update: #30850, on
Windows 8
The VM is the one downloaded when you do

$ wget -O- get.pharo.org/30+vm | bash

Then you open and press F2, Display version information, CogVM 4.0.0 from
May 15 2014.

Script to reproduce it:

Smalltalk garbageCollect.
[  | matrix rows cols tree |
rows := 1.
cols := 1000.
matrix := Matrix rows: rows columns: cols.
 1 to: rows do: [ : r |
1 to: cols do: [ : c |
matrix at: r at: c put: SmallInteger maxVal atRandom ] ].

tree := TreeModel new.
tree columns: (
(1 to: cols) collect: [ : col |
TreeColumnModel new
displayBlock: [ : node | (node content at: col) asString ];
headerLabel: col asString ]).
tree roots: ((1 to: rows) collect: [ : nrow | matrix atRow: nrow ]).
tree openWithSpec ] timeToRun

Hernán



2014-06-26 2:48 GMT-03:00 stepharo :

> Hi hernan
>
> Which image?
> What did you loaded?
> Can you reproduce it?
>
>  Can someone explain what does it mean or why it happens?
>> Is that a common scenario for you?
>>
>> I am measuring execution time for big matrices in CogVM 4.0.0. Image is
>> unresponsive.
>>
>> Cheers,
>>
>> Hernán
>>
>>
>
>

Re: [Pharo-dev] about ~=

[Clément Bera]

Can the parser parse != ?
Can the parser parse ! ?
Both for Opal and the old Compiler ?

Clement


2014-06-26 13:56 GMT+02:00 Christophe Demarey :

> != does not look a good name according to first feedbacks.
> A long version could simply be notEquals:
> For a short version, more opinions/suggestions are welcomed
>
> Le 26 juin 2014 à 13:27, Sven Van Caekenberghe a écrit :
>
> > -1 for replacing ~= with != because it is not better at all
> > +1 for avoiding it altogether like you suggest
> > -1 for changing ~= to mean #closeTo: I like the longer name
> >
> > my 2c
> >
> > On 26 Jun 2014, at 10:15, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
> >
> >> Hi,
> >>
> >> I would like to make a suggestion that may lead to a long debate but
> let's go: What do you think about deprecating ~= and replace it with != for
> example?
> >> Why? In mathematics the symbol ~ is used for equivalence. To me (and I
> think any newcomer to Smalltalk) the first guess of the meaning of ~= is
> equivalent to => missed. The meaning is totally different: "Answer whether
> the receiver and the argument do not represent the same object."
> >>
> >> I never used this method because it is too confusing for me. I prefer
> to use (a = b) not or (a = b) ifFalse:.
> >> So, the discussion is open ...
> >>
> >> Christophe
> >
> >
>
>

Re: [Pharo-dev] Spec, groups and version-specific packages

[Christophe Demarey]

Hi,

You can find useful information into the 'Deep into Pharo' book, chapter 9 
(Managing projects with Metacello), section 9.12 (platform specific package).

Example:
ConfigurationOfCoolBrowser>>baseline09: spec

spec for: #common do: [
spec blessing: #baseline.
spec repository: 'http://www.example.com/CoolBrowser'.
spec
package: 'CoolBrowser-Core';
package: 'CoolBrowser-Tests' with: [ spec requires: 
'CoolBrowser-Core' ];
package: 'CoolBrowser-Addons' with: [ spec requires: 
'CoolBrowser-Core' ];
package: 'CoolBrowser-AddonsTests' with: [
spec requires: #('CoolBrowser-Addons' 
'CoolBrowser-Tests' ) ].
spec
group: 'default' with: #('CoolBrowser-Core' 
'CoolBrowser-Addons' );
group: 'Core' with: #('CoolBrowser-Core' 'CoolBrowser-Platform' 
);
group: 'Extras' with: #('CoolBrowser-Addon');
group: 'Tests' with: #('CoolBrowser-Tests' 
'CoolBrowser-AddonsTests' );
group: 'CompleteWithoutTests' with: #('Core', 'Extras' );
group: 'CompleteWithTests' with: #('CompleteWithoutTests', 
'Tests' )].
spec for: #gemstone do: [
spec package: 'CoolBrowser-Platform' with: 
'CoolBrowser-PlatformGemstone'].
spec for: #pharo do: [
spec package: 'CoolBrowser-Platform' with: 'CoolBrowser-PlatformPharo'].

Le 26 juin 2014 à 13:43, Roberto Minelli a écrit :

> Hi,
> 
> I have my project with my Configuration and I am using spec groups to load 
> different sets of packages (e.g., development and user groups).
> 
> With the porting to Pharo 4.0 I discovered that there are some 
> functionalities specific to Pharo 3.0 and others to Pharo 4.0, for example 
> the fact that MethodContext is no longer part of Pharo 4.0. but it has been 
> replaced by Context.
> 
> I moved such functionalities in a package, say 'MyProject-Extension30’ and 
> Pharo 4.0 specific functionalities in 'MyProject-Extension40’.
> 
> Now the question is, suppose that I have a group like
> spec group: ‘User' with: #(‘A’ ‘B’ ‘C’).
> 
> and another one:
> spec group: ‘Dev' with: #(‘A’ ‘B’ ‘C’ ‘D’ ‘E’).
> 
> Until now, the developer (i.e., me) would do something like
> (self project version: #bleedingEdge) load: #('Dev’)
> 
> and a used of my project would do
> (self project version: #bleedingEdge) load: #(‘User’)
> 
> 
> 
> How can I factor inside the dynamic load of the two Pharo-version specific 
> packages?
> i.e., no matter if ‘User’ or ‘Dev’ group is loaded I need to load 
> 'MyProject-Extension40’ if I am on Pharo 4.0 and 'MyProject-Extension30’ if 
> on Pharo 3.0.
> 
> Thanks for your help,
> Roberto



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] evicted zombie process from run queue

[Esteban Lorenzano]

On 26 Jun 2014, at 02:48, stepharo  wrote:

> Hi hernan
> 
> Which image?
> What did you loaded?
> Can you reproduce it?
- which vm? (CogVM 4.0.0 does not exist or is really old)
- which OS? 

>> Can someone explain what does it mean or why it happens?
>> Is that a common scenario for you?
>> 
>> I am measuring execution time for big matrices in CogVM 4.0.0. Image is 
>> unresponsive.
>> 
>> Cheers,
>> 
>> Hernán
>> 
> 
> 

Re: [Pharo-dev] about ~=

[Christophe Demarey]

!= does not look a good name according to first feedbacks.
A long version could simply be notEquals:
For a short version, more opinions/suggestions are welcomed

Le 26 juin 2014 à 13:27, Sven Van Caekenberghe a écrit :

> -1 for replacing ~= with != because it is not better at all
> +1 for avoiding it altogether like you suggest
> -1 for changing ~= to mean #closeTo: I like the longer name
> 
> my 2c
> 
> On 26 Jun 2014, at 10:15, Christophe Demarey  
> wrote:
> 
>> Hi,
>> 
>> I would like to make a suggestion that may lead to a long debate but let's 
>> go: What do you think about deprecating ~= and replace it with != for 
>> example?
>> Why? In mathematics the symbol ~ is used for equivalence. To me (and I think 
>> any newcomer to Smalltalk) the first guess of the meaning of ~= is 
>> equivalent to => missed. The meaning is totally different: "Answer whether 
>> the receiver and the argument do not represent the same object."
>> 
>> I never used this method because it is too confusing for me. I prefer to use 
>> (a = b) not or (a = b) ifFalse:.
>> So, the discussion is open ...
>> 
>> Christophe
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] Spec, groups and version-specific packages

[Roberto Minelli]

Hi,

I have my project with my Configuration and I am using spec groups to load 
different sets of packages (e.g., development and user groups).

With the porting to Pharo 4.0 I discovered that there are some functionalities 
specific to Pharo 3.0 and others to Pharo 4.0, for example the fact that 
MethodContext is no longer part of Pharo 4.0. but it has been replaced by 
Context.

I moved such functionalities in a package, say 'MyProject-Extension30’ and 
Pharo 4.0 specific functionalities in 'MyProject-Extension40’.

Now the question is, suppose that I have a group like
spec group: ‘User' with: #(‘A’ ‘B’ ‘C’).

and another one:
spec group: ‘Dev' with: #(‘A’ ‘B’ ‘C’ ‘D’ ‘E’).

Until now, the developer (i.e., me) would do something like
(self project version: #bleedingEdge) load: #('Dev’)

and a used of my project would do
(self project version: #bleedingEdge) load: #(‘User’)



How can I factor inside the dynamic load of the two Pharo-version specific 
packages?
i.e., no matter if ‘User’ or ‘Dev’ group is loaded I need to load 
'MyProject-Extension40’ if I am on Pharo 4.0 and 'MyProject-Extension30’ if on 
Pharo 3.0.

Thanks for your help,
Roberto

Re: [Pharo-dev] about ~=

[Yuriy Tymchuk]

On 26 Jun 2014, at 13:27, Sven Van Caekenberghe  wrote:

> -1 for replacing ~= with != because it is not better at all
> +1 for avoiding it altogether like you suggest
> -1 for changing ~= to mean #closeTo: I like the longer name

Yes, but this way we can end up with the names like: #lessThanOrCloseTo: :)

> 
> my 2c
> 
> On 26 Jun 2014, at 10:15, Christophe Demarey  
> wrote:
> 
>> Hi,
>> 
>> I would like to make a suggestion that may lead to a long debate but let's 
>> go: What do you think about deprecating ~= and replace it with != for 
>> example?
>> Why? In mathematics the symbol ~ is used for equivalence. To me (and I think 
>> any newcomer to Smalltalk) the first guess of the meaning of ~= is 
>> equivalent to => missed. The meaning is totally different: "Answer whether 
>> the receiver and the argument do not represent the same object."
>> 
>> I never used this method because it is too confusing for me. I prefer to use 
>> (a = b) not or (a = b) ifFalse:.
>> So, the discussion is open ...
>> 
>> Christophe
> 
> 

Re: [Pharo-dev] Pharo and Amber relationship

[kilon alios]

I will finish Chapter 4 today in the updated PBE and I will give amber
another try and try to contribute.


On Thu, Jun 26, 2014 at 2:13 PM, Yuriy Tymchuk  wrote:

> That’s why there is still no 1.0 version.
>
> Let’s be hones Pharo was forked from Squeak and now has a lot of
> developers. Amber is made from scratch and only a few guys are developing
> it. Everyone is welcome to join as always :)
>
> Uko
>
>
> On 26 Jun 2014, at 12:18, kilon alios  wrote:
>
> One of things that very much annoy me with Amber is its installation , if
> Pharo is installation heaven because it does not need an install ,
> installation of Amber is far from ideal especially if you are not familiar
> with web dev. Also amber is still stuck with the old IDE which is quite
> limited and quite ugly not easy to use. Helios however is shaping up to a
> great IDE and even though it still has a long way to go to reach Pharo
> features its definetly cleaner and better in some areas.
>
> I am not an experienced amber developer or pharo developer by any means
> but my opinion is that even though amber claims that it tries to be
> compatible with Pharo , that's is more a side feature than a main goal.
> Integration wise something like Seaside seems like a much nicer option and
> it integrates very deeply with Pharo. I see amber more like competition to
> Pharo than a cooperative tool, which is not a bad thing at all, I could see
> myself dropping Pharo for Amber if the IDE gets more powerful. Amber
> developers have definitely done a very good job so far,
>
> Another thing I am missing is the pharo debugger. I assume that the
> debugger has a lot of work , maybe years of development till it can be at
> the same level as pharo debugger.
>
> I also dislike the fact that amber does not produce readable javascript
> code.
>
> I know for many people amber as front end and pharo as back end is the way
> to go. But the reality is that javascript with the success of node.js has
> conquered back end library wise. So if amber manages to provide a very good
> IDE and a good debugger, it will be extremely hard to choose Pharo over
> Amber even for desktop apps. Afterall the days that an internet browser was
> just for browsing the internet are long gone for good.
>
> I know I will sound like a heretic , but I think its in the interest of
> Pharo community to support Amber. Html/js looks to me like an ever
> expanding market and I see less and less people going back to coding just
> for desktop. This is also the direction most languages go towards as well.
> I dislike many things about web development but I cannot be any less that
> shocked with the amount of evolution of javascript, internet browsers ,
> html , css and the myriads of third party libraries. If not amber, then
> another way to allow Pharo nice , modern and clean access to web
> technologies. Maybe Seaside is more than enough, or maybe there  better
> ways to integrate amber wth pharo or maybe there is a third party tool that
> I am not aware of.
>
> In any case I will follow this thread with great interest because the
> answer is important to me too.
>
>
> On Thu, Jun 26, 2014 at 11:10 AM, Torsten Bergmann  wrote:
>
>> Hi,
>>
>> as I read somewhere that Amber want to stay compatible
>> with Pharo (at least with the core classes) I wonder
>> how this compatibility is measured/enforced these days.
>>
>> Are there tools to exchange code between the two?
>>
>> I also wonder if what would be necessary to run Amber on
>> Java Nashorn (a JS engine that comes with the JDK 8).
>> Could serve as a horse to also run on JVM...
>>
>> Why I'm asking: I think one of our goals should be to
>> make Pharo more widely usable to not end up as an island.
>>
>> If Pharo and Amber stay compatible to a certain amount
>> Amber could open the door for Pharo to other target platforms
>> (browser, mobile devices, other language runtimes) as
>> JS is available nearly everywhere.
>>
>> Thx
>> T.
>>
>>
>>
>
>

Re: [Pharo-dev] about ~=

[Nicolas Cellier]

2014-06-26 13:17 GMT+02:00 Yuriy Tymchuk :

> I think that while working with float arithmetic it will be nice to
> provide something like #~= instead of #closeTo:, and also add #~<, #~<= and
> so on. But maybe I’m wrong :)
>
> Uko
>
>
Yes, it's wrong because there is no such thing as a universal tolerance.
We need at least two parameters.


> On 26 Jun 2014, at 13:07, Christophe Demarey 
> wrote:
>
>
> Le 26 juin 2014 à 12:46, Nicolas Cellier a écrit :
>
> $! is not classified as a binary character right now, is it?
> Of course it's possible but I'd just say why this particular symbol?
> It does not look mathematical either. Or do you love C/C++ so much?
>
>
> Of course not. It is just because it is something widely used but other
> names could do the stuff like <> or /=
>
> Note that ~= has same meaning in Matlab.
>
> There are other possibilities like /=  or <> (Fortran 95, ADA), even the
> long form =/=.
>
> But frankly, I don't buy this kind of change, for the sake of looking like
> some {} language, making such a deep change is overkill.
>
>
> Indeed it is a deep change but maybe at least we could have an alias and
> use it for all new code. At a time, it will be less painful to do this
> change.
> As expressed in another thread, Smalltalk code convention for method
> naming strategy is *intention revealing*.
> That said, I think ~= is not intention revealing and it will be good to
> fix or propose a good alternative.
>
>
>

Re: [Pharo-dev] about ~=

[Sven Van Caekenberghe]

-1 for replacing ~= with != because it is not better at all
+1 for avoiding it altogether like you suggest
-1 for changing ~= to mean #closeTo: I like the longer name

my 2c

On 26 Jun 2014, at 10:15, Christophe Demarey  
wrote:

> Hi,
> 
> I would like to make a suggestion that may lead to a long debate but let's 
> go: What do you think about deprecating ~= and replace it with != for example?
> Why? In mathematics the symbol ~ is used for equivalence. To me (and I think 
> any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent 
> to => missed. The meaning is totally different: "Answer whether the receiver 
> and the argument do not represent the same object."
> 
> I never used this method because it is too confusing for me. I prefer to use 
> (a = b) not or (a = b) ifFalse:.
> So, the discussion is open ...
> 
> Christophe

[Pharo-dev] [pharo-project/pharo-core] 218e16: 40045

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 218e16ce4a9bb71239a4ab70e436eb6b4f0d61f4
  
https://github.com/pharo-project/pharo-core/commit/218e16ce4a9bb71239a4ab70e436eb6b4f0d61f4
  Author: Jenkins Build Server 
  Date:   2014-06-26 (Thu, 26 Jun 2014)

  Changed paths:
R Nautilus.package/Nautilus.class/class/class 
initialization/registerToolsOn_.st
A Nautilus.package/PackageTreeNautilus.class/class/class 
initialization/registerToolsOn_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script45.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40045.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M System-Hashing.package/SHA256.class/README.md

  Log Message:
  ---
  40045
13410 Wrong Nautilus is registered as default browser
https://pharo.fogbugz.com/f/cases/13410

13395 Add SHA256 HashFunction
https://pharo.fogbugz.com/f/cases/13395

http://files.pharo.org/image/40/40045.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40045
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] about ~=

[Yuriy Tymchuk]

I think that while working with float arithmetic it will be nice to provide 
something like #~= instead of #closeTo:, and also add #~<, #~<= and so on. But 
maybe I’m wrong :)

Uko
On 26 Jun 2014, at 13:07, Christophe Demarey  
wrote:

> 
> Le 26 juin 2014 à 12:46, Nicolas Cellier a écrit :
> 
>> $! is not classified as a binary character right now, is it?
>> Of course it's possible but I'd just say why this particular symbol?
>> It does not look mathematical either. Or do you love C/C++ so much?
> 
> Of course not. It is just because it is something widely used but other names 
> could do the stuff like <> or /=
> 
>> Note that ~= has same meaning in Matlab.
>> 
>> There are other possibilities like /=  or <> (Fortran 95, ADA), even the 
>> long form =/=.
>> 
>> But frankly, I don't buy this kind of change, for the sake of looking like 
>> some {} language, making such a deep change is overkill.
> 
> Indeed it is a deep change but maybe at least we could have an alias and use 
> it for all new code. At a time, it will be less painful to do this change.
> As expressed in another thread, Smalltalk code convention for method naming 
> strategy is intention revealing.
> That said, I think ~= is not intention revealing and it will be good to fix 
> or propose a good alternative.

Re: [Pharo-dev] Pharo and Amber relationship

[Yuriy Tymchuk]

That’s why there is still no 1.0 version.

Let’s be hones Pharo was forked from Squeak and now has a lot of developers. 
Amber is made from scratch and only a few guys are developing it. Everyone is 
welcome to join as always :)

Uko

On 26 Jun 2014, at 12:18, kilon alios  wrote:

> One of things that very much annoy me with Amber is its installation , if 
> Pharo is installation heaven because it does not need an install , 
> installation of Amber is far from ideal especially if you are not familiar 
> with web dev. Also amber is still stuck with the old IDE which is quite 
> limited and quite ugly not easy to use. Helios however is shaping up to a 
> great IDE and even though it still has a long way to go to reach Pharo 
> features its definetly cleaner and better in some areas. 
> 
> I am not an experienced amber developer or pharo developer by any means but 
> my opinion is that even though amber claims that it tries to be compatible 
> with Pharo , that's is more a side feature than a main goal. Integration wise 
> something like Seaside seems like a much nicer option and it integrates very 
> deeply with Pharo. I see amber more like competition to Pharo than a 
> cooperative tool, which is not a bad thing at all, I could see myself 
> dropping Pharo for Amber if the IDE gets more powerful. Amber developers have 
> definitely done a very good job so far,
> 
> Another thing I am missing is the pharo debugger. I assume that the debugger 
> has a lot of work , maybe years of development till it can be at the same 
> level as pharo debugger. 
> 
> I also dislike the fact that amber does not produce readable javascript code. 
>  
> 
> I know for many people amber as front end and pharo as back end is the way to 
> go. But the reality is that javascript with the success of node.js has 
> conquered back end library wise. So if amber manages to provide a very good 
> IDE and a good debugger, it will be extremely hard to choose Pharo over Amber 
> even for desktop apps. Afterall the days that an internet browser was just 
> for browsing the internet are long gone for good. 
> 
> I know I will sound like a heretic , but I think its in the interest of Pharo 
> community to support Amber. Html/js looks to me like an ever expanding market 
> and I see less and less people going back to coding just for desktop. This is 
> also the direction most languages go towards as well. I dislike many things 
> about web development but I cannot be any less that shocked with the amount 
> of evolution of javascript, internet browsers , html , css and the myriads of 
> third party libraries. If not amber, then another way to allow Pharo nice , 
> modern and clean access to web technologies. Maybe Seaside is more than 
> enough, or maybe there  better ways to integrate amber wth pharo or maybe 
> there is a third party tool that I am not aware of.
> 
> In any case I will follow this thread with great interest because the answer 
> is important to me too. 
> 
> 
> On Thu, Jun 26, 2014 at 11:10 AM, Torsten Bergmann  wrote:
> Hi,
> 
> as I read somewhere that Amber want to stay compatible
> with Pharo (at least with the core classes) I wonder
> how this compatibility is measured/enforced these days.
> 
> Are there tools to exchange code between the two?
> 
> I also wonder if what would be necessary to run Amber on
> Java Nashorn (a JS engine that comes with the JDK 8).
> Could serve as a horse to also run on JVM...
> 
> Why I'm asking: I think one of our goals should be to
> make Pharo more widely usable to not end up as an island.
> 
> If Pharo and Amber stay compatible to a certain amount
> Amber could open the door for Pharo to other target platforms
> (browser, mobile devices, other language runtimes) as
> JS is available nearly everywhere.
> 
> Thx
> T.
> 
> 
> 

Re: [Pharo-dev] about ~=

[Christophe Demarey]

Le 26 juin 2014 à 12:46, Nicolas Cellier a écrit :

> $! is not classified as a binary character right now, is it?
> Of course it's possible but I'd just say why this particular symbol?
> It does not look mathematical either. Or do you love C/C++ so much?

Of course not. It is just because it is something widely used but other names 
could do the stuff like <> or /=

> Note that ~= has same meaning in Matlab.
> 
> There are other possibilities like /=  or <> (Fortran 95, ADA), even the long 
> form =/=.
> 
> But frankly, I don't buy this kind of change, for the sake of looking like 
> some {} language, making such a deep change is overkill.

Indeed it is a deep change but maybe at least we could have an alias and use it 
for all new code. At a time, it will be less painful to do this change.
As expressed in another thread, Smalltalk code convention for method naming 
strategy is intention revealing.
That said, I think ~= is not intention revealing and it will be good to fix or 
propose a good alternative.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] about ~=

[Nicolas Cellier]

$! is not classified as a binary character right now, is it?
Of course it's possible but I'd just say why this particular symbol?
It does not look mathematical either. Or do you love C/C++ so much?

Note that ~= has same meaning in Matlab.

There are other possibilities like /=  or <> (Fortran 95, ADA), even the
long form =/=.

But frankly, I don't buy this kind of change, for the sake of looking like
some {} language, making such a deep change is overkill.

In any case, a big -1 for !=


2014-06-26 10:47 GMT+02:00 Max Leske :

>
> On 26.06.2014, at 10:15, Christophe Demarey 
> wrote:
>
> > Hi,
> >
> > I would like to make a suggestion that may lead to a long debate but
> let's go: What do you think about deprecating ~= and replace it with != for
> example?
> > Why? In mathematics the symbol ~ is used for equivalence. To me (and I
> think any newcomer to Smalltalk) the first guess of the meaning of ~= is
> equivalent to => missed. The meaning is totally different: "Answer whether
> the receiver and the argument do not represent the same object.”
>
> +1
> But then I also want to suggest #!== for negating identity.
>
> >
> > I never used this method because it is too confusing for me. I prefer to
> use (a = b) not or (a = b) ifFalse:.
> > So, the discussion is open ...
> >
> > Christophe
>
>
>

Re: [Pharo-dev] Pharo and Amber relationship

[kilon alios]

One of things that very much annoy me with Amber is its installation , if
Pharo is installation heaven because it does not need an install ,
installation of Amber is far from ideal especially if you are not familiar
with web dev. Also amber is still stuck with the old IDE which is quite
limited and quite ugly not easy to use. Helios however is shaping up to a
great IDE and even though it still has a long way to go to reach Pharo
features its definetly cleaner and better in some areas.

I am not an experienced amber developer or pharo developer by any means but
my opinion is that even though amber claims that it tries to be compatible
with Pharo , that's is more a side feature than a main goal. Integration
wise something like Seaside seems like a much nicer option and it
integrates very deeply with Pharo. I see amber more like competition to
Pharo than a cooperative tool, which is not a bad thing at all, I could see
myself dropping Pharo for Amber if the IDE gets more powerful. Amber
developers have definitely done a very good job so far,

Another thing I am missing is the pharo debugger. I assume that the
debugger has a lot of work , maybe years of development till it can be at
the same level as pharo debugger.

I also dislike the fact that amber does not produce readable javascript
code.

I know for many people amber as front end and pharo as back end is the way
to go. But the reality is that javascript with the success of node.js has
conquered back end library wise. So if amber manages to provide a very good
IDE and a good debugger, it will be extremely hard to choose Pharo over
Amber even for desktop apps. Afterall the days that an internet browser was
just for browsing the internet are long gone for good.

I know I will sound like a heretic , but I think its in the interest of
Pharo community to support Amber. Html/js looks to me like an ever
expanding market and I see less and less people going back to coding just
for desktop. This is also the direction most languages go towards as well.
I dislike many things about web development but I cannot be any less that
shocked with the amount of evolution of javascript, internet browsers ,
html , css and the myriads of third party libraries. If not amber, then
another way to allow Pharo nice , modern and clean access to web
technologies. Maybe Seaside is more than enough, or maybe there  better
ways to integrate amber wth pharo or maybe there is a third party tool that
I am not aware of.

In any case I will follow this thread with great interest because the
answer is important to me too.


On Thu, Jun 26, 2014 at 11:10 AM, Torsten Bergmann  wrote:

> Hi,
>
> as I read somewhere that Amber want to stay compatible
> with Pharo (at least with the core classes) I wonder
> how this compatibility is measured/enforced these days.
>
> Are there tools to exchange code between the two?
>
> I also wonder if what would be necessary to run Amber on
> Java Nashorn (a JS engine that comes with the JDK 8).
> Could serve as a horse to also run on JVM...
>
> Why I'm asking: I think one of our goals should be to
> make Pharo more widely usable to not end up as an island.
>
> If Pharo and Amber stay compatible to a certain amount
> Amber could open the door for Pharo to other target platforms
> (browser, mobile devices, other language runtimes) as
> JS is available nearly everywhere.
>
> Thx
> T.
>
>
>

Re: [Pharo-dev] Refactorings - Push down several instVars

[Stephan Eggermont]

Hi Phil,

You might want to take a look at the refactoring engine code. 
In the image it is not so well documented. The way it is used 
in Nautilus might help you. 

There used to be a RewriteTool that was designed for large scale
refactorings (using regular expressions), but I don't know if
that was resurrected already.

Stephan

Re: [Pharo-dev] super initialize

[Benjamin]

On 26 Jun 2014, at 11:30, Damien Cassou  wrote:

> On Thu, Jun 26, 2014 at 9:46 AM, Torsten Bergmann  wrote:
>> But the question is should we care if there may be
>> in the future?
> 
> 
> I think there is a lint rule that checks if #initialize calls super 
> initialise.

on instance side only


Ben


> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
> 

Re: [Pharo-dev] about ~=

[Damien Cassou]

On Thu, Jun 26, 2014 at 11:29 AM, Yuriy Tymchuk  wrote:
> For me ~ looks more like closeTo:


so you also agree then

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-dev] super initialize

[Damien Cassou]

On Thu, Jun 26, 2014 at 9:46 AM, Torsten Bergmann  wrote:
> But the question is should we care if there may be
> in the future?


I think there is a lint rule that checks if #initialize calls super initialize.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-dev] about ~=

[Yuriy Tymchuk]

For me ~ looks more like closeTo:

Uko

On 26 Jun 2014, at 10:15, Christophe Demarey  
wrote:

> Hi,
> 
> I would like to make a suggestion that may lead to a long debate but let's 
> go: What do you think about deprecating ~= and replace it with != for example?
> Why? In mathematics the symbol ~ is used for equivalence. To me (and I think 
> any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent 
> to => missed. The meaning is totally different: "Answer whether the receiver 
> and the argument do not represent the same object."
> 
> I never used this method because it is too confusing for me. I prefer to use 
> (a = b) not or (a = b) ifFalse:.
> So, the discussion is open ...
> 
> Christophe

Re: [Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing

[François Stephany]

Thanks Sven!


On Wed, Jun 25, 2014 at 10:46 AM, Sven Van Caekenberghe 
wrote:

> A patch mechanism ?
>
> That would be cool indeed, although probably not doable in all cases.
>
> On 25 Jun 2014, at 10:23, Norbert Hartl  wrote:
>
> > Wouldn't it be wonderful if we could install packages from a ticket in
> the image? Something like
> >
> > - get 3.0 image
> > - fix from issue 12345 and issue 45678 and...
> > - install own own packages
> > - deploy
> >
> > It would be so well documented :)
> >
> > Norbert
> >
> > Am 25.06.2014 um 08:47 schrieb Sven Van Caekenberghe :
> >
> >> I only did it in 3.0
> >> The file out is attached to the slice - it is 100% standalone
> >>
> >> On 25 Jun 2014, at 00:45, Norbert Hartl  wrote:
> >>
> >>> thank you, Sven. Did you try this in 3.0, too. I would need it there!
> >>>
> >>> Norbert
> >>>
>  Am 25.06.2014 um 00:11 schrieb Sven Van Caekenberghe :
> 
>  https://pharo.fogbugz.com/f/cases/13395/Add-SHA256-HashFunction
> 
>  cleaned up, documented, properly packaged.
> 
>  Passes some test vectors.
> 
>  I changed the handling of the empty stream.
> 
> > On 24 Jun 2014, at 23:03, Sven Van Caekenberghe 
> wrote:
> >
> > Hi Jan,
> >
> > I loaded just the class CFSHA256 and it worked perfectly (I didn't
> expect anything else).
> >
> > I tried some examples from Wikipedia (
> http://en.wikipedia.org/wiki/Sha256#Examples_of_SHA-2_variants):
> >
> > (CFSHA256 hashMessage: 'The quick brown fox jumps over the lazy
> dog') hex.
> 'd7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592'
> >
> > (CFSHA256 hashMessage: 'The quick brown fox jumps over the lazy
> dog.') hex.
> 'ef537f25c895bfa782526529a9b63d97aa631564d5d789c2b765448c8635fb6c'
> >
> > So I will rename the class to SHA256, moving it to System-Hashing
> and add SHA256Tests for starters.
> >
> > Sven
> >
> >> On 20 Jun 2014, at 17:01, Jan van de Sandt 
> wrote:
> >>
> >> Hello,
> >>
> >> I added the SHA256 class to Cloudfork a few years ago. The class
> was mostly copied from the Cryptography [1] project.
> >>
> >> Cheers,
> >> Jan.
> >>
> >> [1] http://www.squeaksource.com/Cryptography/
> >>
> >>
> >> On Fri, Jun 20, 2014 at 10:56 AM, François Stephany <
> tulipe.mouta...@gmail.com> wrote:
> >> Max,
> >>
> >> Yes, it's usable as the SHA1 package already there (without HMAC
> so). I'm no expert in those stuff but I don't get "SHA256 base
> implementation". Someone with more knowledge can probably tell ;)
> >>
> >> Sven,
> >>
> >> The bare minimum to load it is:
> >>
> >> Gofer it
> >> smalltalkhubUser: 'JanVanDeSandt' project: 'Cloudfork';
> >> package: 'Cloudfork-Common';
> >> package: 'Cloudfork-Pharo-Platform';
> >> load.
> >>
> >> The implementation is in Cloudfork-Pharo-Platform.
> >>
> >>
> >>
> >> On Thu, Jun 19, 2014 at 6:20 PM, Sven Van Caekenberghe <
> s...@stfx.eu> wrote:
> >> I want to have a look, if you tell me where to look...
> >>
> >>> On 19 Jun 2014, at 18:03, Max Leske  wrote:
> >>>
> >>>
>  On 19.06.2014, at 17:59, François Stephany <
> tulipe.mouta...@gmail.com> wrote:
> 
>  Does it make sense from a license point of view and practical
> point of view to include the CloudFork HMAC-SHA256 implementation (CFSH256
> class) in the System-Hashing package (in  where there's already SHA1 and
> MD5) ?
> >>>
> >>> Can Cloudfork HMAC-SHA256 be easily parameterized with, say, an
> SHA256 base implementation? Or does it require extra stuff? In the former
> case I probably wouldn’t add it. In the latter case it’s open for
> discussion. Personally, I think it belongs into a separate package, not
> into System-Hashing.
> >>>
> >>> Cheers,
> >>> Max
> 
> 
> >>>
> >>
> >>
> >
> >
>
>
>

[Pharo-dev] Refactorings - Push down several instVars

[p...@highoctane.be]

It is only possible to do this one variable at a time...

How to do a set of vars all at once?

Same story for quite a couple of refactorings...

Thanks in advance!
Phil

Re: [Pharo-dev] about ~=

[Max Leske]

On 26.06.2014, at 10:15, Christophe Demarey  wrote:

> Hi,
> 
> I would like to make a suggestion that may lead to a long debate but let's 
> go: What do you think about deprecating ~= and replace it with != for example?
> Why? In mathematics the symbol ~ is used for equivalence. To me (and I think 
> any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent 
> to => missed. The meaning is totally different: "Answer whether the receiver 
> and the argument do not represent the same object.”

+1
But then I also want to suggest #!== for negating identity.

> 
> I never used this method because it is too confusing for me. I prefer to use 
> (a = b) not or (a = b) ifFalse:.
> So, the discussion is open ...
> 
> Christophe

Re: [Pharo-dev] Spec Button Shortcut Indication

[Benjamin]

On 25 Jun 2014, at 20:40, Sean P. DeNigris  wrote:

> Benjamin Van Ryseghem (Pharo) wrote
>> It’s intentional that the C is underlined.
> 
> Cool!! One of the few good ideas from Windoze…

Now we have to remove it! ;)


Ben


> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Spec-Button-Shortcut-Indication-tp4764414p4764778.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

[Pharo-dev] about ~=

[Christophe Demarey]

Hi,

I would like to make a suggestion that may lead to a long debate but let's go: 
What do you think about deprecating ~= and replace it with != for example?
Why? In mathematics the symbol ~ is used for equivalence. To me (and I think 
any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent 
to => missed. The meaning is totally different: "Answer whether the receiver 
and the argument do not represent the same object."

I never used this method because it is too confusing for me. I prefer to use (a 
= b) not or (a = b) ifFalse:.
So, the discussion is open ...

Christophe

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] R: [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

[Sven Van Caekenberghe]

On 26 Jun 2014, at 09:24, Lorenzo Schiavina  wrote:

> Great job Sven, I felt young again.
>  
> Thank you.
>  
> Lorenzo

Yeah, I am beginning to realise that being interested in historic calculators 
puts you in a certain age bracket ;-)

I am glad you liked it.

Sven

[Pharo-dev] Pharo and Amber relationship

[Torsten Bergmann]

Hi,

as I read somewhere that Amber want to stay compatible
with Pharo (at least with the core classes) I wonder
how this compatibility is measured/enforced these days.

Are there tools to exchange code between the two?

I also wonder if what would be necessary to run Amber on
Java Nashorn (a JS engine that comes with the JDK 8).
Could serve as a horse to also run on JVM...

Why I'm asking: I think one of our goals should be to 
make Pharo more widely usable to not end up as an island.

If Pharo and Amber stay compatible to a certain amount
Amber could open the door for Pharo to other target platforms
(browser, mobile devices, other language runtimes) as
JS is available nearly everywhere.

Thx
T.

Re: [Pharo-dev] [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

[Sven Van Caekenberghe]

On 25 Jun 2014, at 17:05, Sven Van Caekenberghe  wrote:

> Apparently it already got posted on YC News
> 
>  https://news.ycombinator.com/item?id=7943876
> 
> so it needs votes and comments to survive.

Let's try again - it is hard to get up the rankings, both votes & comments help 
- thanks.

[Pharo-dev] super initialize

[Torsten Bergmann]

When you create a new instance with #new automatically
#initialize is sent.

The default #initialize is provided in ProtoObject at
the highest level of the class hierarchy (doing nothing). 

If you look deeper in the hierarchy you will notice that 

 - some subclasses of Object override the #initialize
   method and call "super initialize"
 - some subclasses of Object override the #initialize
   method without calling "super initialize"

No problem at the moment as there is no initialization
done in Object or ProtoObject at the current point in
time.

But the question is should we care if there may be 
in the future? 

Thx
T.

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

[Goubier Thierry]

Sorry to ask then, but:

would it be possible to profile a configurationOf... load with and 
without a Nautilus open? Time spent handling announcements should be 
visible, and, yes, when loading code, Browsers have to be aware the code 
is being changed.


I spent some time optimizing that for AltBrowser, and it can  very 
significantly increase the loading time, without counting in side 
effects such as over-caching (and I know Nautilus does some caching, but 
I'm not sure I understand why).


Thierry

Le 25/06/2014 20:20, p...@highoctane.be a écrit :

Maybe due to some Annoucement being picked up by Nautilus?

Phil



On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau mailto:jo...@inceptive.be>> wrote:

Hi,

It seems that when even a single Nautilus system browser is open and
you do a load (using Metacello), there is a huge amount of objects
that get created and persisted in the image.
This even leads to the point that the image crashes when I try to
load our code using a ConfigurationOf. After some time, the Pharo
process is stuck at 100%, image size is over 500MB and the entire
image becomes unresponsive, finally crashing after an hour or so.

I have not yet found which objects or why, but I just wrestled with
this all day to find out what was going on. I first thought that
Metacello was in an infinite loop but after noticing that the image
was so large (500MB) and that it got reduced to 20% of its size
after closing the browser window, I can say that Nautilus is
gathering garbage. It is definitely not Metacello because I can
trigger the same problem doing a load via Monticello only.

When I load the ConfigurationOf without a single browser open, it
loads 5x faster and the image size stays reasonable.

Is this a known issue? Any thoughts on what may be causing this?

regards!
Johan




--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95