Re: [Pharo-dev] Question on Package comments [SO]

[Alain Rastoul]

I agree with Kilon.
May be he is true about a lack of a package/class reference 
documentation/system like in java or dotnet but I find the question a 
little biased and  SO policy is right on that : "questions to find (...) 
tools, libraries (...)  are off-topic, they tend to attract opinionated 
answers and spam. Describe the problem (...)".
If he already downloaded the VM, he could have asked in the newsgroup 
instead.
May be building a tool (javadoc like, extracting class and method 
comments with additional tags) could be of some interest ?

Not only for newcomers.

Regards,

Alain

Le 18/10/2014 02:54, Sean P. DeNigris a écrit :

Nicolai Hess wrote

I disagree and I downvoted the question because its clear he did not even
bother to google for documentation.

He asked: "Does there exist any comprehensive reference for what each one
[Package] is"
The answer is "no". How can he found this out without asking?


I have to agree with Nicolai here. He wasn't asking "how do I find the docs
for package Xyz?" in which case search would be obvious. What exactly would
he type into google to find out if Pharo had a package catalog, like Squeak
Map? I think it's a logical question that could be difficult to google.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Question-on-Package-comments-SO-tp4785191p4785240.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Question on Package comments [SO]

[Sean P. DeNigris]

Nicolai Hess wrote
>> I disagree and I downvoted the question because its clear he did not even
>> bother to google for documentation.
> He asked: "Does there exist any comprehensive reference for what each one
> [Package] is"
> The answer is "no". How can he found this out without asking?

I have to agree with Nicolai here. He wasn't asking "how do I find the docs
for package Xyz?" in which case search would be obvious. What exactly would
he type into google to find out if Pharo had a package catalog, like Squeak
Map? I think it's a logical question that could be difficult to google.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Question-on-Package-comments-SO-tp4785191p4785240.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Question on Package comments [SO]

[Nicolai Hess]

2014-10-18 0:38 GMT+02:00 kilon alios :

> I disagree and I downvoted the question because its clear he did not even
> bother to google for documentation.
>

He asked: "Does there exist any comprehensive reference for what each one
[Package] is"
The answer is "no". How can he found this out without asking?

Re: [Pharo-dev] Question on Package comments [SO]

[kilon alios]

I disagree and I downvoted the question because its clear he did not even
bother to google for documentation. Maybe he forgot or maybe he meants
something else than it is already available.  I am mostly against SO strict
policy but in this case I will have to agree with it, the question is too
vague for it anyway.


On Sat, Oct 18, 2014 at 1:27 AM, Nicolai Hess  wrote:

> 2014-10-17 23:43 GMT+02:00 Sean P. DeNigris :
>
>> Nicolai Hess wrote
>> > It is a valid question
>>
>> I agree. And at the same time, after reading their reasoning, while
>> seemingly overzealous, their decision seems logically sound based on SO
>> rules. I added this comment:
>>
>> I think that the closest you have is
>> ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/…, which is an
>> attempt-in-progress in making a package catalog. Also, most better-known
>> Pharo projects seem to be hosted on SmalltalkHub which provides a Markdown
>> description for each project (provided of course that someone has filled
>> it
>> out!)
>>
>
> thank you!
>
>
>
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context:
>> http://forum.world.st/Question-on-Package-comments-SO-tp4785191p4785223.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>

Re: [Pharo-dev] Question on Package comments [SO]

[Nicolai Hess]

2014-10-17 23:43 GMT+02:00 Sean P. DeNigris :

> Nicolai Hess wrote
> > It is a valid question
>
> I agree. And at the same time, after reading their reasoning, while
> seemingly overzealous, their decision seems logically sound based on SO
> rules. I added this comment:
>
> I think that the closest you have is
> ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/…, which is an
> attempt-in-progress in making a package catalog. Also, most better-known
> Pharo projects seem to be hosted on SmalltalkHub which provides a Markdown
> description for each project (provided of course that someone has filled it
> out!)
>

thank you!



>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Question-on-Package-comments-SO-tp4785191p4785223.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Question on Package comments [SO]

[Sean P. DeNigris]

Nicolai Hess wrote
> It is a valid question

I agree. And at the same time, after reading their reasoning, while
seemingly overzealous, their decision seems logically sound based on SO
rules. I added this comment:

I think that the closest you have is
ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/…, which is an
attempt-in-progress in making a package catalog. Also, most better-known
Pharo projects seem to be hosted on SmalltalkHub which provides a Markdown
description for each project (provided of course that someone has filled it
out!)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Question-on-Package-comments-SO-tp4785191p4785223.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Richard Sargent]

Ben Coman wrote
> Richard Sargent wrote:
>> Eliot Miranda-2 wrote
>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>> 
>>> richard.sargent@
>> 
 wrote:
 One of the best things about Smalltalk is how easily we can say what we
 mean. I think you would be better off creating a method named something
 like
 #hasSameEffectAs: to answer what you are presently using #= to do, and
 change #= to answer the, in my opinion, more sensible "is the same as"
 that
 we conventionally think of #= meaning.

>>> But that's the point.  #= has to mean something and having it mean #==
>>> isn't useful, so one has to choose some value-based semantic for
>>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>>> means for some value type is far easier than defining what it might mean
>>> for something as complex as a CompiledMethod.  The definition in
>>> Squeak/Pharo has been useful to me in implementing a closure-based
>>> system,
>>> so I'm unapologetic about the current definition.  It is a good one but
>>> it
>>> doesn't preclude defining others.
>> 
>> An interesting response. You ignored the point that e.g.
>> #hasSameEffectAs:
>> provides greater clarity and add an argument against something I didn't
>> say.
>> 
>> I also don't think defining equality for a CompiledMethod is particularly
>> difficult. If I were to recompile a method's source code, I would get a
>> new
>> instance of a CompiledMethod that would, in my opinion, be equal to the
>> one
>> already installed in the class (and perhaps cached in the VM's
>> optimizations). So one would be able to say that we would not replace an
>> existing CompiledMethod with an equal one. The current implementation of
>> #=
>> has no such characteristic, since it proclaims a CompiledMethod named #a
>> to
>> be equal to one named #z.
>> 
> 
> @Richard
> 
> That doesn't seem to be a good example for what your trying to say.
> Given...
> 
> [1] SomeClass>>a "original instance"
>   ^1
> 
> [2] SomeClass>>a "recompiled instance"
>   ^1
> 
> [3] SomeClass>>z
>   ^1
> 
> ...you seem to be saying that its useful to know if [1]=[2],
> but imply that is invalidated by [2]=[3] ?
> 
> But [1]=[2] remains true, and just as useful for your example.

Ben, I believe you are correct. I did not think deeply enough about how
using #= would work. In retrospect, it looks like my hypothesized scenarios
would not be problematic.

But I will stand by my argument about naming methods. The philosophical
technique Reductio ad Absurdum will be useful here.

If I began a method declaration as follows, everyone would agree it was bad.
fred: another
"Answer whether I have the same effect as @another."

I believe almost everyone would agree the mistake in that is that the
comment should be unnecessary because the method name should explain its
purpose.


One of the best heuristics I have ever encountered for naming things is to
start by "explaining to a colleague" (perhaps an imaginary one) what the
thing does, then strip out every word which does not affect the meaning.
[This last step would almost certainly prevent the inclusion of phrases like
"when executing" in a CompiledMethod method, in my opinion.]



> @Max
> 
> I guess to call it a bug, you bumped into a different use case
> where [2]=[3] is problematic. Can you describe that?
> 
> 
> cheers -ben
> 
> 
>> The blue book say #= means "Answer whether the receiver and the argument
>> represent the same component." The current implementation does so only
>> for
>> some, in my opinion, counter-intuitive definition of "same component".
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>> 
>>





--
View this message in context: 
http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4785205.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] TLS SNI[1] for SqueakSSL on unix

[stepharo]

Might be interesting for some of you.



Hi,

I've implemented support for TLS SNI[1] for SqueakSSL on unix. I've 
uploaded the modified source files[2][3], a diff[4], and a prebuilt 
module[5] (built on Ubuntu 14.04 from the Cog branch).
The image side code is also available[6], along with an updated version 
of the WebClient[7] package, and intermediate packages with various 
improvements[8].
The image side code works even if the plugin doesn't support TLS SNI, 
but this version of WebClient won't work with older versions of the 
SqueakSSL-Core package.
Please review the changes, and consider adding them to the corresponding 
repositories!


Levente

[1] https://en.wikipedia.org/wiki/Server_Name_Indication
[2] http://leves.web.elte.hu/squeak/SqueakSSL/SqueakSSL.h
[3] http://leves.web.elte.hu/squeak/SqueakSSL/sqUnixOpenSSL.c
[4] http://leves.web.elte.hu/squeak/SqueakSSL/diff.txt
[5] http://leves.web.elte.hu/squeak/SqueakSSL/SqueakSSL
[6] http://leves.web.elte.hu/squeak/SqueakSSL/SqueakSSL-Core-ul.29.mcz
[7] http://leves.web.elte.hu/squeak/SqueakSSL/WebClient-Core-ul.98.mcz
[8] http://leves.web.elte.hu/squeak/SqueakSSL/

Re: [Pharo-dev] [Ann] Phratch 4.0

[stepharo]

I love this item list :)

After the version 3.0 that was a release for usability and stability, 
phratch 4.0 is released to prepare the future.


The new features are:

- phratch is more modular, eg having a kernel and lots of addons.
- cleaning a lot the source code
- customizable environment
- each block can be made visible or invisible
- each category can be made visible or invisible
- it is possible to add translation for addons with the pragma 
 in the class PhratchTranslator. This make 
the translation more modular.
- first integration of phratch with the pharo environment. Using the 
pragma at the class side of any class in Pharo make the class visible 
and usable in phratch.
- There is a lot of things to do with phratch, you are welcome to 
contribute ! The documentation for new features will arrive soon.

Re: [Pharo-dev] [ANN] New Gold Member LabWare

[Esteban A. Maringolo]

Indeed it is.

AFAIR Andres Valloud works there.

Regards!
Esteban A. Maringolo


2014-10-17 12:36 GMT-03:00 Sven Van Caekenberghe :
> This is excellent news.
>
> On 15 Oct 2014, at 14:00, Marcus Denker  wrote:
>
>> The Pharo Consortium is very happy to announce that LabWare has joined the 
>> Consortium as a Gold Industrial Member.
>>
>> About LabWare:
>> "LabWare is recognized as the global leader in providing enterprise scale 
>> laboratory automation solutions.
>> Our Enterprise Laboratory Platform combines the award-winning LabWare LIMS™ 
>> and LabWare ELN™, a
>> comprehensive and fully integrated Electronic Laboratory Notebook 
>> application, which enables companies
>> to optimize compliance, improve quality, increase productivity and reduce 
>> costs. LabWare is a full service
>> provider offering software, professional implementation services and 
>> validation assistance, training, and
>> world class technical support to ensure our customers get the maximum value 
>> from their LabWare products."
>>
>>  - LabWare: http://www.labware.com
>>  - Pharo Consortium: http://consortium.pharo.org
>>
>> The goal of the Pharo Consortium is to allow companies to support the 
>> ongoing development and future of Pharo.
>> Individuals can support Pharo via the Pharo Association:  
>> http://association.pharo.org
>
>

Re: [Pharo-dev] [ANN] New Gold Member LabWare

[Sven Van Caekenberghe]

This is excellent news.

On 15 Oct 2014, at 14:00, Marcus Denker  wrote:

> The Pharo Consortium is very happy to announce that LabWare has joined the 
> Consortium as a Gold Industrial Member. 
> 
> About LabWare:
> "LabWare is recognized as the global leader in providing enterprise scale 
> laboratory automation solutions.  
> Our Enterprise Laboratory Platform combines the award-winning LabWare LIMS™ 
> and LabWare ELN™, a 
> comprehensive and fully integrated Electronic Laboratory Notebook 
> application, which enables companies 
> to optimize compliance, improve quality, increase productivity and reduce 
> costs. LabWare is a full service 
> provider offering software, professional implementation services and 
> validation assistance, training, and 
> world class technical support to ensure our customers get the maximum value 
> from their LabWare products."
> 
>  - LabWare: http://www.labware.com
>  - Pharo Consortium: http://consortium.pharo.org
> 
> The goal of the Pharo Consortium is to allow companies to support the ongoing 
> development and future of Pharo.
> Individuals can support Pharo via the Pharo Association:  
> http://association.pharo.org

[Pharo-dev] Question on Package comments [SO]

[Nicolai Hess]

There was a question on SO about documentations for Packages:
http://stackoverflow.com/questions/26292060/is-there-any-pharo-package-reference-documentation

I don't have enough reputation for adding comments in SO,
therefore, I ask the questions here:

The question is closed and I don't understand why.
It is a valid question and I do
remember that this was a topic on this list as well:
show document/help text in configuration browser/
tooltip for packages in Nautilus/
comment package like it is done for classes.

For that user, who asked the question on SO:
At least for external packages there are sometimes some
information on github or squeaksource and we should show him
a link to the pharo user mailing list.



(and no, the http://lmgtfy.com/ link is not helpful nor funny)


nicolai

Re: [Pharo-dev] PharoNOS

[mikefilonov]

I have updated the ISO

- Changed the disk setup - now it is more safe - it finds first disk without
a partition table and use it for persistance. If no such disk found ISO
works from memory.
- Added PharoLaucher as a default Image
- Added sqlite3 driver (not test yet though)
- Made Pharo run by root user so all files are editable now

I was not able to fix AioPlugin as seems there is no compiled version for
Linux.

Please check the new ISO out and share your feedback.

You may get the ISO here: 

https://drive.google.com/folderview?id=0B7FTL05bnHyud2lCWHN0LUdTd1E&usp=sharing#list

"pharonos 2.iso"



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

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 16:41, Eliot Miranda  wrote:
> 
> Hi Max,
> 
> On Oct 17, 2014, at 7:24 AM, Max Leske  > wrote:
> 
>> 
>>> On 17.10.2014, at 15:52, Nicolas Cellier 
>>> >> > wrote:
>>> 
>>> 
>>> 
>>> 2014-10-17 15:49 GMT+02:00 Max Leske >> >:
>>> 
 On 17.10.2014, at 15:25, Eliot Miranda >>> > wrote:
 
 Hi Max,
 
 On Oct 17, 2014, at 12:34 AM, Max Leske >>> > wrote:
 
> 
>> On 17.10.2014, at 02:46, Ben Coman > > wrote:
>> 
>> Richard Sargent wrote:
>>> Eliot Miranda-2 wrote
 On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
 richard.sargent@
> wrote:
> One of the best things about Smalltalk is how easily we can say what 
> we
> mean. I think you would be better off creating a method named 
> something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as"
> that
> we conventionally think of #= meaning.
> 
 But that's the point.  #= has to mean something and having it mean #==
 isn't useful, so one has to choose some value-based semantic for
 CompiledMethod>>#= and the one that's there is useful.  Defining what 
 #=
 means for some value type is far easier than defining what it might 
 mean
 for something as complex as a CompiledMethod.  The definition in
 Squeak/Pharo has been useful to me in implementing a closure-based 
 system,
 so I'm unapologetic about the current definition.  It is a good one 
 but it
 doesn't preclude defining others.
>>> An interesting response. You ignored the point that e.g. 
>>> #hasSameEffectAs:
>>> provides greater clarity and add an argument against something I didn't 
>>> say.
>>> I also don't think defining equality for a CompiledMethod is 
>>> particularly
>>> difficult. If I were to recompile a method's source code, I would get a 
>>> new
>>> instance of a CompiledMethod that would, in my opinion, be equal to the 
>>> one
>>> already installed in the class (and perhaps cached in the VM's
>>> optimizations). So one would be able to say that we would not replace an
>>> existing CompiledMethod with an equal one. The current implementation 
>>> of #=
>>> has no such characteristic, since it proclaims a CompiledMethod named 
>>> #a to
>>> be equal to one named #z.
>> 
>> @Richard
>> 
>> That doesn't seem to be a good example for what your trying to say.
>> Given...
>> 
>> [1] SomeClass>>a "original instance"
>>  ^1
>> 
>> [2] SomeClass>>a "recompiled instance"
>>  ^1
>> 
>> [3] SomeClass>>z
>>  ^1
>> 
>> ...you seem to be saying that its useful to know if [1]=[2],
>> but imply that is invalidated by [2]=[3] ?
>> 
>> But [1]=[2] remains true, and just as useful for your example.
>> 
>> 
>> @Max
>> 
>> I guess to call it a bug, you bumped into a different use case
>> where [2]=[3] is problematic. Can you describe that?
> 
> Well, not problematic. Once you accept that neither selector nor class 
> are part of a CompiledMethod it is obvious that two instances with the 
> same byte codes produce the same hash.
> 
> The actual problem is more one of understanding and use. The following 
> code answers a collection with the CompiledMethods Collection>>add:, 
> Collection>>do: and Collection>>remove:ifAbsent:
> 
> Collection methods select: #isAbstract.
> 
> All three CompiledMethods are implemented as ‘^ self 
> subclassResponsibility’, so they have the same byte codes. Now, if you 
> take that collection and make a set out of it you’ll lose Collection>>do: 
> since #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t 
> because the number of arguments is calculated into the hash (actually the 
> CompiledMethod header is).
 
 Surely the issue is that "aClass methods" should answer an IdentitySet 
 right?
>>> 
>>> Well, in the case of my example that wouldn’t change anything. As soon as 
>>> you put the methods into a set you’ll end up with less entries than before 
>>> again. Selectors are unique per class anyway so I don’t quite see the 
>>> benefit of using an IdentitySet over an OrderedCollection (or a Bag for 
>>> that matter), except for making it more obvious that the result of the 
>>> message #methods doesn’t need to be filtered further.
>>> 
>>> I should add that the code, the student who discovered the clash wrote, 
>>> looked more like this:
>>> 
>>> result := Set new.
>>> Collection meth

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Eliot Miranda]

Hi Max,

On Oct 17, 2014, at 7:24 AM, Max Leske  wrote:

> 
>> On 17.10.2014, at 15:52, Nicolas Cellier 
>>  wrote:
>> 
>> 
>> 
>> 2014-10-17 15:49 GMT+02:00 Max Leske :
>>> 
 On 17.10.2014, at 15:25, Eliot Miranda  wrote:
 
 Hi Max,
 
 On Oct 17, 2014, at 12:34 AM, Max Leske  wrote:
 
> 
>> On 17.10.2014, at 02:46, Ben Coman  wrote:
>> 
>> Richard Sargent wrote:
>>> Eliot Miranda-2 wrote
 On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
 richard.sargent@
> wrote:
> One of the best things about Smalltalk is how easily we can say what 
> we
> mean. I think you would be better off creating a method named 
> something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as"
> that
> we conventionally think of #= meaning.
 But that's the point.  #= has to mean something and having it mean #==
 isn't useful, so one has to choose some value-based semantic for
 CompiledMethod>>#= and the one that's there is useful.  Defining what 
 #=
 means for some value type is far easier than defining what it might 
 mean
 for something as complex as a CompiledMethod.  The definition in
 Squeak/Pharo has been useful to me in implementing a closure-based 
 system,
 so I'm unapologetic about the current definition.  It is a good one 
 but it
 doesn't preclude defining others.
>>> An interesting response. You ignored the point that e.g. 
>>> #hasSameEffectAs:
>>> provides greater clarity and add an argument against something I didn't 
>>> say.
>>> I also don't think defining equality for a CompiledMethod is 
>>> particularly
>>> difficult. If I were to recompile a method's source code, I would get a 
>>> new
>>> instance of a CompiledMethod that would, in my opinion, be equal to the 
>>> one
>>> already installed in the class (and perhaps cached in the VM's
>>> optimizations). So one would be able to say that we would not replace an
>>> existing CompiledMethod with an equal one. The current implementation 
>>> of #=
>>> has no such characteristic, since it proclaims a CompiledMethod named 
>>> #a to
>>> be equal to one named #z.
>> 
>> @Richard
>> 
>> That doesn't seem to be a good example for what your trying to say.
>> Given...
>> 
>> [1] SomeClass>>a "original instance"
>>  ^1
>> 
>> [2] SomeClass>>a "recompiled instance"
>>  ^1
>> 
>> [3] SomeClass>>z
>>  ^1
>> 
>> ...you seem to be saying that its useful to know if [1]=[2],
>> but imply that is invalidated by [2]=[3] ?
>> 
>> But [1]=[2] remains true, and just as useful for your example.
>> 
>> 
>> @Max
>> 
>> I guess to call it a bug, you bumped into a different use case
>> where [2]=[3] is problematic. Can you describe that?
> 
> Well, not problematic. Once you accept that neither selector nor class 
> are part of a CompiledMethod it is obvious that two instances with the 
> same byte codes produce the same hash.
> 
> The actual problem is more one of understanding and use. The following 
> code answers a collection with the CompiledMethods Collection>>add:, 
> Collection>>do: and Collection>>remove:ifAbsent:
> 
> Collection methods select: #isAbstract.
> 
> All three CompiledMethods are implemented as ‘^ self 
> subclassResponsibility’, so they have the same byte codes. Now, if you 
> take that collection and make a set out of it you’ll lose Collection>>do: 
> since #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t 
> because the number of arguments is calculated into the hash (actually the 
> CompiledMethod header is).
 
 Surely the issue is that "aClass methods" should answer an IdentitySet 
 right?
>>> 
>>> Well, in the case of my example that wouldn’t change anything. As soon as 
>>> you put the methods into a set you’ll end up with less entries than before 
>>> again. Selectors are unique per class anyway so I don’t quite see the 
>>> benefit of using an IdentitySet over an OrderedCollection (or a Bag for 
>>> that matter), except for making it more obvious that the result of the 
>>> message #methods doesn’t need to be filtered further.
>>> 
>>> I should add that the code, the student who discovered the clash wrote, 
>>> looked more like this:
>>> 
>>> result := Set new.
>>> Collection methods do: [ :m |
>>> m isAbstract ifTrue: [ result add: m ] ].
>>> 
>>> Max
>> 
>> Why not just keep a dictionary, like methodDictionary select: #isAbstract or 
>> something like that…
> 
> You’re right of course, there’s no need to put methods into a set. The code 
> is from an exercise 

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Eliot Miranda]

Hi Max,


On Oct 17, 2014, at 6:49 AM, Max Leske  wrote:

> 
>> On 17.10.2014, at 15:25, Eliot Miranda  wrote:
>> 
>> Hi Max,
>> 
>> On Oct 17, 2014, at 12:34 AM, Max Leske  wrote:
>> 
>>> 
 On 17.10.2014, at 02:46, Ben Coman  wrote:
 
 Richard Sargent wrote:
> Eliot Miranda-2 wrote
>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>> richard.sargent@
>>> wrote:
>>> One of the best things about Smalltalk is how easily we can say what we
>>> mean. I think you would be better off creating a method named something
>>> like
>>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>>> change #= to answer the, in my opinion, more sensible "is the same as"
>>> that
>>> we conventionally think of #= meaning.
>> But that's the point.  #= has to mean something and having it mean #==
>> isn't useful, so one has to choose some value-based semantic for
>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>> means for some value type is far easier than defining what it might mean
>> for something as complex as a CompiledMethod.  The definition in
>> Squeak/Pharo has been useful to me in implementing a closure-based 
>> system,
>> so I'm unapologetic about the current definition.  It is a good one but 
>> it
>> doesn't preclude defining others.
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't 
> say.
> I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a 
> new
> instance of a CompiledMethod that would, in my opinion, be equal to the 
> one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of 
> #=
> has no such characteristic, since it proclaims a CompiledMethod named #a 
> to
> be equal to one named #z.
 
 @Richard
 
 That doesn't seem to be a good example for what your trying to say.
 Given...
 
 [1] SomeClass>>a "original instance"
^1
 
 [2] SomeClass>>a "recompiled instance"
^1
 
 [3] SomeClass>>z
^1
 
 ...you seem to be saying that its useful to know if [1]=[2],
 but imply that is invalidated by [2]=[3] ?
 
 But [1]=[2] remains true, and just as useful for your example.
 
 
 @Max
 
 I guess to call it a bug, you bumped into a different use case
 where [2]=[3] is problematic. Can you describe that?
>>> 
>>> Well, not problematic. Once you accept that neither selector nor class are 
>>> part of a CompiledMethod it is obvious that two instances with the same 
>>> byte codes produce the same hash.
>>> 
>>> The actual problem is more one of understanding and use. The following code 
>>> answers a collection with the CompiledMethods Collection>>add:, 
>>> Collection>>do: and Collection>>remove:ifAbsent:
>>> 
>>> Collection methods select: #isAbstract.
>>> 
>>> All three CompiledMethods are implemented as ‘^ self 
>>> subclassResponsibility’, so they have the same byte codes. Now, if you take 
>>> that collection and make a set out of it you’ll lose Collection>>do: since 
>>> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because 
>>> the number of arguments is calculated into the hash (actually the 
>>> CompiledMethod header is).
>> 
>> Surely the issue is that "aClass methods" should answer an IdentitySet right?
> 
> Well, in the case of my example that wouldn’t change anything. As soon as you 
> put the methods into a set you’ll end up with less entries than before again.

No.  An IdentitySet uses #== and identityHash so that won't be the case.  Also 
IIRC. anIdentitySet collect: answers another IdentitySet.


> Selectors are unique per class anyway so I don’t quite see the benefit of 
> using an IdentitySet over an OrderedCollection (or a Bag for that matter), 
> except for making it more obvious that the result of the message #methods 
> doesn’t need to be filtered further.

Well then (IdentitySet withAll: aClass methods) collect: will not lose 
elements.  You'd have exactly the same issue if you tried to collect the set of 
all literals in the system.  Unless you used an IdentitySet you'd collect only 
the different values, not all literals.  Or any set of all objects that 
represent values.


> I should add that the code, the student who discovered the clash wrote, 
> looked more like this:
> 
> result := Set new.
> Collection methods do: [ :m |
>   m isAbstract ifTrue: [ result add: m ] ].

So change it to IdentitySet new.  This is good for the student to encounter.  
It is one of the essential differences between OO and function

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 15:52, Nicolas Cellier  
> wrote:
> 
> 
> 
> 2014-10-17 15:49 GMT+02:00 Max Leske  >:
> 
>> On 17.10.2014, at 15:25, Eliot Miranda > > wrote:
>> 
>> Hi Max,
>> 
>> On Oct 17, 2014, at 12:34 AM, Max Leske > > wrote:
>> 
>>> 
 On 17.10.2014, at 02:46, Ben Coman >>> > wrote:
 
 Richard Sargent wrote:
> Eliot Miranda-2 wrote
>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>> richard.sargent@
>>> wrote:
>>> One of the best things about Smalltalk is how easily we can say what we
>>> mean. I think you would be better off creating a method named something
>>> like
>>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>>> change #= to answer the, in my opinion, more sensible "is the same as"
>>> that
>>> we conventionally think of #= meaning.
>>> 
>> But that's the point.  #= has to mean something and having it mean #==
>> isn't useful, so one has to choose some value-based semantic for
>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>> means for some value type is far easier than defining what it might mean
>> for something as complex as a CompiledMethod.  The definition in
>> Squeak/Pharo has been useful to me in implementing a closure-based 
>> system,
>> so I'm unapologetic about the current definition.  It is a good one but 
>> it
>> doesn't preclude defining others.
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't 
> say.
> I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a 
> new
> instance of a CompiledMethod that would, in my opinion, be equal to the 
> one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of 
> #=
> has no such characteristic, since it proclaims a CompiledMethod named #a 
> to
> be equal to one named #z.
 
 @Richard
 
 That doesn't seem to be a good example for what your trying to say.
 Given...
 
 [1] SomeClass>>a "original instance"
^1
 
 [2] SomeClass>>a "recompiled instance"
^1
 
 [3] SomeClass>>z
^1
 
 ...you seem to be saying that its useful to know if [1]=[2],
 but imply that is invalidated by [2]=[3] ?
 
 But [1]=[2] remains true, and just as useful for your example.
 
 
 @Max
 
 I guess to call it a bug, you bumped into a different use case
 where [2]=[3] is problematic. Can you describe that?
>>> 
>>> Well, not problematic. Once you accept that neither selector nor class are 
>>> part of a CompiledMethod it is obvious that two instances with the same 
>>> byte codes produce the same hash.
>>> 
>>> The actual problem is more one of understanding and use. The following code 
>>> answers a collection with the CompiledMethods Collection>>add:, 
>>> Collection>>do: and Collection>>remove:ifAbsent:
>>> 
>>> Collection methods select: #isAbstract.
>>> 
>>> All three CompiledMethods are implemented as ‘^ self 
>>> subclassResponsibility’, so they have the same byte codes. Now, if you take 
>>> that collection and make a set out of it you’ll lose Collection>>do: since 
>>> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because 
>>> the number of arguments is calculated into the hash (actually the 
>>> CompiledMethod header is).
>> 
>> Surely the issue is that "aClass methods" should answer an IdentitySet right?
> 
> Well, in the case of my example that wouldn’t change anything. As soon as you 
> put the methods into a set you’ll end up with less entries than before again. 
> Selectors are unique per class anyway so I don’t quite see the benefit of 
> using an IdentitySet over an OrderedCollection (or a Bag for that matter), 
> except for making it more obvious that the result of the message #methods 
> doesn’t need to be filtered further.
> 
> I should add that the code, the student who discovered the clash wrote, 
> looked more like this:
> 
> result := Set new.
> Collection methods do: [ :m |
>   m isAbstract ifTrue: [ result add: m ] ].
> 
> Max
> 
> 
> Why not just keep a dictionary, like methodDictionary select: #isAbstract or 
> something like that…

You’re right of course, there’s no need to put methods into a set. The code is 
from an exercise and the students aren’t used to Smalltalk, so they end up with 
all sorts of code.

>  
>> 
>> 
>>> So, as long as you think of CompiledMethods as objects that have a name, it 
>>> looks like a bug and in m

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Nicolas Cellier]

2014-10-17 15:49 GMT+02:00 Max Leske :

>
> On 17.10.2014, at 15:25, Eliot Miranda  wrote:
>
> Hi Max,
>
> On Oct 17, 2014, at 12:34 AM, Max Leske  wrote:
>
>
> On 17.10.2014, at 02:46, Ben Coman  wrote:
>
> Richard Sargent wrote:
>
> Eliot Miranda-2 wrote
>
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>
> richard.sargent@
>
> wrote:
> One of the best things about Smalltalk is how easily we can say what we
> mean. I think you would be better off creating a method named something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as"
> that
> we conventionally think of #= meaning.
>
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.
>
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't
> say.
> I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a new
> instance of a CompiledMethod that would, in my opinion, be equal to the one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of #=
> has no such characteristic, since it proclaims a CompiledMethod named #a to
> be equal to one named #z.
>
>
> @Richard
>
> That doesn't seem to be a good example for what your trying to say.
> Given...
>
> [1] SomeClass>>a "original instance"
> ^1
>
> [2] SomeClass>>a "recompiled instance"
> ^1
>
> [3] SomeClass>>z
> ^1
>
> ...you seem to be saying that its useful to know if [1]=[2],
> but imply that is invalidated by [2]=[3] ?
>
> But [1]=[2] remains true, and just as useful for your example.
>
>
> @Max
>
> I guess to call it a bug, you bumped into a different use case
> where [2]=[3] is problematic. Can you describe that?
>
>
> Well, not problematic. Once you accept that neither selector nor class are
> part of a CompiledMethod it is obvious that two instances with the same
> byte codes produce the same hash.
>
> The actual problem is more one of understanding and use. The following
> code answers a collection with the CompiledMethods Collection>>add:,
> Collection>>do: and Collection>>remove:ifAbsent:
>
> Collection methods select: #isAbstract.
>
>
> All three CompiledMethods are implemented as ‘^ self
> subclassResponsibility’, so they have the same byte codes. Now, if you take
> that collection and make a set out of it you’ll lose Collection>>do: since
> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because
> the number of arguments is calculated into the hash (actually the
> CompiledMethod header is).
>
>
> Surely the issue is that "aClass methods" should answer an IdentitySet
> right?
>
>
> Well, in the case of my example that wouldn’t change anything. As soon as
> you put the methods into a set you’ll end up with less entries than before
> again. Selectors are unique per class anyway so I don’t quite see the
> benefit of using an IdentitySet over an OrderedCollection (or a Bag for
> that matter), except for making it more obvious that the result of the
> message #methods doesn’t need to be filtered further.
>
> I should add that the code, the student who discovered the clash wrote,
> looked more like this:
>
> result := Set new.
> Collection methods do: [ :m |
> m isAbstract ifTrue: [ result add: m ] ].
>
> Max
>
>
Why not just keep a dictionary, like methodDictionary select: #isAbstract
or something like that...


>
>
> So, as long as you think of CompiledMethods as objects that have a name,
> it looks like a bug and in my opinion this behaviour is something that
> messes with the mind of newcomers. Just a (silly) idea: something like a
> CompiledMethodWrapper might solve the problem (at least from the user
> perspective; everything is slightly different from the VM perspective :) ),
> as it could hold on to the class and the selector independently of the
> actual CompiledMethod.
>
> In the end however, one doesn’t work with compiled methods a lot and the
> hash situation is unlikely to cause a lot of problems (people working with
> CompiledMethod usually know what they are doing).
>
> Cheers,
> Max
>
>
>
> cheers -ben
>
>
> The blue book say #= means "Answer whether the receiver and the argument
> represent the same component." The current implementation d

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 15:25, Eliot Miranda  wrote:
> 
> Hi Max,
> 
> On Oct 17, 2014, at 12:34 AM, Max Leske  > wrote:
> 
>> 
>>> On 17.10.2014, at 02:46, Ben Coman >> > wrote:
>>> 
>>> Richard Sargent wrote:
 Eliot Miranda-2 wrote
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
> richard.sargent@
>> wrote:
>> One of the best things about Smalltalk is how easily we can say what we
>> mean. I think you would be better off creating a method named something
>> like
>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>> change #= to answer the, in my opinion, more sensible "is the same as"
>> that
>> we conventionally think of #= meaning.
>> 
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.
 An interesting response. You ignored the point that e.g. #hasSameEffectAs:
 provides greater clarity and add an argument against something I didn't 
 say.
 I also don't think defining equality for a CompiledMethod is particularly
 difficult. If I were to recompile a method's source code, I would get a new
 instance of a CompiledMethod that would, in my opinion, be equal to the one
 already installed in the class (and perhaps cached in the VM's
 optimizations). So one would be able to say that we would not replace an
 existing CompiledMethod with an equal one. The current implementation of #=
 has no such characteristic, since it proclaims a CompiledMethod named #a to
 be equal to one named #z.
>>> 
>>> @Richard
>>> 
>>> That doesn't seem to be a good example for what your trying to say.
>>> Given...
>>> 
>>> [1] SomeClass>>a "original instance"
>>> ^1
>>> 
>>> [2] SomeClass>>a "recompiled instance"
>>> ^1
>>> 
>>> [3] SomeClass>>z
>>> ^1
>>> 
>>> ...you seem to be saying that its useful to know if [1]=[2],
>>> but imply that is invalidated by [2]=[3] ?
>>> 
>>> But [1]=[2] remains true, and just as useful for your example.
>>> 
>>> 
>>> @Max
>>> 
>>> I guess to call it a bug, you bumped into a different use case
>>> where [2]=[3] is problematic. Can you describe that?
>> 
>> Well, not problematic. Once you accept that neither selector nor class are 
>> part of a CompiledMethod it is obvious that two instances with the same byte 
>> codes produce the same hash.
>> 
>> The actual problem is more one of understanding and use. The following code 
>> answers a collection with the CompiledMethods Collection>>add:, 
>> Collection>>do: and Collection>>remove:ifAbsent:
>> 
>> Collection methods select: #isAbstract.
>> 
>> All three CompiledMethods are implemented as ‘^ self 
>> subclassResponsibility’, so they have the same byte codes. Now, if you take 
>> that collection and make a set out of it you’ll lose Collection>>do: since 
>> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because 
>> the number of arguments is calculated into the hash (actually the 
>> CompiledMethod header is).
> 
> Surely the issue is that "aClass methods" should answer an IdentitySet right?

Well, in the case of my example that wouldn’t change anything. As soon as you 
put the methods into a set you’ll end up with less entries than before again. 
Selectors are unique per class anyway so I don’t quite see the benefit of using 
an IdentitySet over an OrderedCollection (or a Bag for that matter), except for 
making it more obvious that the result of the message #methods doesn’t need to 
be filtered further.

I should add that the code, the student who discovered the clash wrote, looked 
more like this:

result := Set new.
Collection methods do: [ :m |
m isAbstract ifTrue: [ result add: m ] ].

Max

> 
> 
>> So, as long as you think of CompiledMethods as objects that have a name, it 
>> looks like a bug and in my opinion this behaviour is something that messes 
>> with the mind of newcomers. Just a (silly) idea: something like a 
>> CompiledMethodWrapper might solve the problem (at least from the user 
>> perspective; everything is slightly different from the VM perspective :) ), 
>> as it could hold on to the class and the selector independently of the 
>> actual CompiledMethod.
>> 
>> In the end however, one doesn’t work with compiled methods a lot and the 
>> hash situation is unlikely to cause a lot of problems (people working with 
>> CompiledMethod usually know what they are doing).
>> 
>> Cheers,
>> Max
>> 
>>> 
>>> 
>>

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Eliot Miranda]

Hi Max,

On Oct 17, 2014, at 12:34 AM, Max Leske  wrote:

> 
>> On 17.10.2014, at 02:46, Ben Coman  wrote:
>> 
>> Richard Sargent wrote:
>>> Eliot Miranda-2 wrote
 On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
 richard.sargent@
> wrote:
> One of the best things about Smalltalk is how easily we can say what we
> mean. I think you would be better off creating a method named something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as"
> that
> we conventionally think of #= meaning.
 But that's the point.  #= has to mean something and having it mean #==
 isn't useful, so one has to choose some value-based semantic for
 CompiledMethod>>#= and the one that's there is useful.  Defining what #=
 means for some value type is far easier than defining what it might mean
 for something as complex as a CompiledMethod.  The definition in
 Squeak/Pharo has been useful to me in implementing a closure-based system,
 so I'm unapologetic about the current definition.  It is a good one but it
 doesn't preclude defining others.
>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
>>> provides greater clarity and add an argument against something I didn't say.
>>> I also don't think defining equality for a CompiledMethod is particularly
>>> difficult. If I were to recompile a method's source code, I would get a new
>>> instance of a CompiledMethod that would, in my opinion, be equal to the one
>>> already installed in the class (and perhaps cached in the VM's
>>> optimizations). So one would be able to say that we would not replace an
>>> existing CompiledMethod with an equal one. The current implementation of #=
>>> has no such characteristic, since it proclaims a CompiledMethod named #a to
>>> be equal to one named #z.
>> 
>> @Richard
>> 
>> That doesn't seem to be a good example for what your trying to say.
>> Given...
>> 
>> [1] SomeClass>>a "original instance"
>>  ^1
>> 
>> [2] SomeClass>>a "recompiled instance"
>>  ^1
>> 
>> [3] SomeClass>>z
>>  ^1
>> 
>> ...you seem to be saying that its useful to know if [1]=[2],
>> but imply that is invalidated by [2]=[3] ?
>> 
>> But [1]=[2] remains true, and just as useful for your example.
>> 
>> 
>> @Max
>> 
>> I guess to call it a bug, you bumped into a different use case
>> where [2]=[3] is problematic. Can you describe that?
> 
> Well, not problematic. Once you accept that neither selector nor class are 
> part of a CompiledMethod it is obvious that two instances with the same byte 
> codes produce the same hash.
> 
> The actual problem is more one of understanding and use. The following code 
> answers a collection with the CompiledMethods Collection>>add:, 
> Collection>>do: and Collection>>remove:ifAbsent:
> 
> Collection methods select: #isAbstract.
> 
> All three CompiledMethods are implemented as ‘^ self subclassResponsibility’, 
> so they have the same byte codes. Now, if you take that collection and make a 
> set out of it you’ll lose Collection>>do: since #do: and #add: produce the 
> same hash, but #remove:ifAbsent: doesn’t because the number of arguments is 
> calculated into the hash (actually the CompiledMethod header is).

Surely the issue is that "aClass methods" should answer an IdentitySet right?


> So, as long as you think of CompiledMethods as objects that have a name, it 
> looks like a bug and in my opinion this behaviour is something that messes 
> with the mind of newcomers. Just a (silly) idea: something like a 
> CompiledMethodWrapper might solve the problem (at least from the user 
> perspective; everything is slightly different from the VM perspective :) ), 
> as it could hold on to the class and the selector independently of the actual 
> CompiledMethod.
> 
> In the end however, one doesn’t work with compiled methods a lot and the hash 
> situation is unlikely to cause a lot of problems (people working with 
> CompiledMethod usually know what they are doing).
> 
> Cheers,
> Max
> 
>> 
>> 
>> cheers -ben
>> 
>> 
>>> The blue book say #= means "Answer whether the receiver and the argument
>>> represent the same component." The current implementation does so only for
>>> some, in my opinion, counter-intuitive definition of "same component".
>>> --
>>> View this message in context: 
>>> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Eliot (phone)

Re: [Pharo-dev] [squeak-dev] New Spur trunk image available

[Eliot Miranda]

Hi Levente,

On Oct 17, 2014, at 5:40 AM, Levente Uzonyi  wrote:

> On Thu, 16 Oct 2014, Eliot Miranda wrote:
> 
>> Hi All,
>> finally the Spur Squeak trunk image is updateable.  The image in 
>> http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created 
>> today and thanks to Bert Freudenberg's latest Monticello work can
>> be updated independently of the non-Spur trunk.  Spur VMs are available in 
>> http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they 
>> appear).  Without wanting to appear too overconfident the Spur
>> system looks to be ready for use apart from image segments (which I hope to 
>> have working some time next month).  I'm really interested in having this 
>> stress tested by as many people as possible.  Spur really
>> does offer a significant performance and functionality improvement over the 
>> current system, but it needs testing to ensure its reliability.
> 
> Great news.
> 
>> Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope 
>> Pharo 4 Spur will be available soon.
>> As far as trunk goes, using Spur alongside non-Spur trunk is going to be 
>> difficult to manage for the near future.  Right now, Spur modifies the 
>> Collections, Compiler, Kernel and System packages, and this is
>> done by auto-editing the non-Spur versions of those packages, something I do 
>> periodically as new versions arrive.  I also auto-edit trunk configurations 
>> (the part of the image update scheme that ensures
>> packages are loaded in the right order when there are dependencies between 
>> packages) from non-Spur "update" to Spur "update.spur" forms.  This at east 
>> means that Spur can keep up with trunk.  But it does
>> /not/ provide a way of committing to Collections.spur, Compiler.spur, 
>> Kernel.spur or System.spur without getting out of sync with non-Spur trunk.  
>> Note that apart from these packages, one /can/ safely commit
>> any other package from a Spur image to trunk.
>> Right now the plan is to release both V3 (the pre-Spur format) and Spur 
>> versions of Squeak 4.6 (I hope it'll be called Squeak 5.0).  This isn't my 
>> preference.  I'd like to see just Spur released, once
>> reliability is verified.  But I understand the safety and 
>> backward-compatibility concerns (Spur won't be able to load V3 image 
>> segments, and vice verse).  The issue is of course that we have this tricky
>> package situation to manage where, to keep the two systems in sync, 
>> modifications to Collections, Compiler, Kernel and System need to be 
>> committed from V3 and auto-edited to Spur. I think that's too clumsy to
>> be practicable.  Perhaps allowing the two systems to fork and doing a manual 
>> merge will be acceptable, but it'll be work to keep them in sync.
> 
> How about releasing the V3 version as Squeak 4.6, and the Spur version as 
> Squeak 5.0 at the same time?
> This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is 
> released, then - leaving V3 behind - use the Trunk for Spur-only.
> Then any changes could be backported manually to the future squeak46 
> repository if needed.

Works for me.  Good idea!  Objections?


> Levente
> 
>> --
>> best,Eliot

Eliot (phone)

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

[Marcus Denker]

-- 
Marcus Denker
Sent with Airmail

On 17 Oct 2014 at 12:46:28, Esteban Lorenzano (esteba...@gmail.com) wrote:

that i don’t know. 
the change is already there or the slice is actually empty. 
nothing to do with the app, in that case :)


But I checked: the Slices did show me content when I reviewed them, these change
are *not* there, yet, the merge is empty.

Esteban

On 17 Oct 2014, at 12:28, Marcus Denker  wrote:


On 17 Oct 2014, at 12:21, Esteban Lorenzano  wrote:

that means most probably a merge conflict (still not handled by new integrator 
app). 
Sorry, I will fix it soon :)


But I wonder why when I merge the not-integrated slices, it claims that there 
is no change?


Esteban

On 17 Oct 2014, at 12:19, Marcus Denker  wrote:

We will have to revert this.

-> the changes are not there
-> yet when I merge the Slice it claims there are no changes.
-> So we have to revert.

On Fri, Oct 17, 2014 at 11:56 AM, GitHub  wrote:
  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db
      
https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502aca8caacaac75dc1db
  Author: Jenkins Build Server 
  Date:   2014-10-17 (Fri, 17 Oct 2014)

  Changed paths:
    A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script310.st
    A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40310.st
    M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40310
14246 CompiledMethod>>hash can produce clashes
        https://pharo.fogbugz.com/f/cases/14246

14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core
        https://pharo.fogbugz.com/f/cases/14257

14253 MC dependency warning should name which package is failing to load
        https://pharo.fogbugz.com/f/cases/14253

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





--
--
Marcus Denker  --  den...@acm.org
http://www.marcusdenker.de

Re: [Pharo-dev] Mysteries of the compiler

[Marcus Denker]

-- 
Marcus Denker
Sent with Airmail

On 17 Oct 2014 at 12:46:20, Nicolai Hess (nicolaih...@web.de) wrote:

I ran some testcases with your changes and I expect some test
are failing now, but actually they don't fail but others do.



Yes, but I think these tests are wrong. 
(needs to be carefully checked).



2014-10-16 22:06 GMT+02:00 Nicolai Hess :
2014-10-16 17:40 GMT+02:00 Marcus Denker :
>>
>> While in the write we need to mark:
>>
>> lookupVariableForWrite: aVariableNode
>>
>>      | var |
>>
>>      var := scope lookupVar: aVariableNode name.
>>
>>      var ifNil: [^var].
>>      var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: 
>>aVariableNode ].
>>      var isWritable ifFalse: [ self storeIntoReadOnlyVariable: aVariableNode 
>>].
>>
>>      var isTemp ifTrue: [
>>              "when in a loop, all writes escape"
>>              scope outerScope isInsideOptimizedLoop ifTrue: [ var 
>>markEscapingWrite ].
>>              "else only escaping when they will end up in different closures"
>>              (var scope outerNotOptimizedScope ~= scope 
>>outerNotOptimizedScope)
>>                      ifTrue: [ var markEscapingWrite]].
>>      ^var
>>
>>
>> I checked that all Opal tests that are failing are actually testing wrong, 
>> and I double checked
>> that all those methods are now compiled like with the old old compiler…
>> Now recompilng the image.
>
> Hmm… nope…. something wrong.
>

the “outerScope” was wrong.

So without that, I can recompile the image and your example is compiled without 
temp vectors…

        Marcus

good!
I'll open an issue on fogbugz and create a slice with your changes.

about reordering of tempvars:
It would be nice if the order preserves, but I think we can live with it.
Although there is an issue with the debugger:
14058 Inconsistent information in debugger
I solved that one by using tempvar names instead if the index, but
this has another issue (sometimes the last (or most nested) tempvar is always 
nil).

The real error is, EyeDebuggerContextInspector does recognizes if the index 
changes
(somewhere in EyeDebuggerContextInspector>>#updateList it
compares the new elements (with new indices) with the old elements list
and skips the update)

Re: [Pharo-dev] [Pharo-users] [Ann] Phratch 4.0

[Sven Van Caekenberghe]

Excellent work. Thank you.

On 17 Oct 2014, at 11:48, jannik laval  wrote:

> Phratch 4.0 is out of the box !
> 
> Phratch 4.0 is cleaner, faster and more stable than phratch 3.0.
> 
> After the version 3.0 that was a release for usability and stability, phratch 
> 4.0 is released to prepare the future.
> 
> The new features are:
> 
> - phratch is more modular, eg having a kernel and lots of addons.
> - cleaning a lot the source code
> - customizable environment
> - each block can be made visible or invisible
> - each category can be made visible or invisible
> - it is possible to add translation for addons with the pragma 
>  in the class PhratchTranslator. This make the 
> translation more modular.
> - first integration of phratch with the pharo environment. Using the pragma 
> at the class side of any class in Pharo make the class visible and usable in 
> phratch.
> - There is a lot of things to do with phratch, you are welcome to contribute 
> ! The documentation for new features will arrive soon.
> 
> See you on phratch.com
> 
> -- 
> ~~Jannik Laval~~
> École des Mines de Douai
> Enseignant-chercheur
> http://www.jannik-laval.eu
> http://www.phratch.com
> http://www.approchealpes.info
> http://car.mines-douai.fr/
> 

Re: [Pharo-dev] Mysteries of the compiler

[Nicolai Hess]

I ran some testcases with your changes and I expect some test
are failing now, but actually they don't fail but others do.




2014-10-16 22:06 GMT+02:00 Nicolai Hess :

> 2014-10-16 17:40 GMT+02:00 Marcus Denker :
>
>> >>
>> >> While in the write we need to mark:
>> >>
>> >> lookupVariableForWrite: aVariableNode
>> >>
>> >>  | var |
>> >>
>> >>  var := scope lookupVar: aVariableNode name.
>> >>
>> >>  var ifNil: [^var].
>> >>  var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable:
>> aVariableNode ].
>> >>  var isWritable ifFalse: [ self storeIntoReadOnlyVariable:
>> aVariableNode ].
>> >>
>> >>  var isTemp ifTrue: [
>> >>  "when in a loop, all writes escape"
>> >>  scope outerScope isInsideOptimizedLoop ifTrue: [ var
>> markEscapingWrite ].
>> >>  "else only escaping when they will end up in different
>> closures"
>> >>  (var scope outerNotOptimizedScope ~= scope
>> outerNotOptimizedScope)
>> >>  ifTrue: [ var markEscapingWrite]].
>> >>  ^var
>> >>
>> >>
>> >> I checked that all Opal tests that are failing are actually testing
>> wrong, and I double checked
>> >> that all those methods are now compiled like with the old old compiler…
>> >> Now recompilng the image.
>> >
>> > Hmm… nope…. something wrong.
>> >
>>
>> the “outerScope” was wrong.
>>
>> So without that, I can recompile the image and your example is compiled
>> without temp vectors…
>>
>> Marcus
>>
>
> good!
> I'll open an issue on fogbugz and create a slice with your changes.
>
> about reordering of tempvars:
> It would be nice if the order preserves, but I think we can live with it.
> Although there is an issue with the debugger:
> 14058  Inconsistent
> information in debugger
> I solved that one by using tempvar names instead if the index, but
> this has another issue (sometimes the last (or most nested) tempvar is
> always nil).
>
> The real error is, EyeDebuggerContextInspector does recognizes if the
> index changes
> (somewhere in EyeDebuggerContextInspector>>#updateList it
> compares the new elements (with new indices) with the old elements list
> and skips the update)
>
>
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

[Esteban Lorenzano]

that i don’t know. 
the change is already there or the slice is actually empty. 
nothing to do with the app, in that case :)

Esteban

> On 17 Oct 2014, at 12:28, Marcus Denker  wrote:
> 
> 
>> On 17 Oct 2014, at 12:21, Esteban Lorenzano > > wrote:
>> 
>> that means most probably a merge conflict (still not handled by new 
>> integrator app). 
>> Sorry, I will fix it soon :)
>> 
> 
> But I wonder why when I merge the not-integrated slices, it claims that there 
> is no change?
> 
> 
>> Esteban
>> 
>>> On 17 Oct 2014, at 12:19, Marcus Denker >> > wrote:
>>> 
>>> We will have to revert this.
>>> 
>>> -> the changes are not there
>>> -> yet when I merge the Slice it claims there are no changes.
>>> -> So we have to revert.
>>> 
>>> On Fri, Oct 17, 2014 at 11:56 AM, GitHub >> > wrote:
>>>   Branch: refs/heads/4.0
>>>   Home:   https://github.com/pharo-project/pharo-core 
>>> 
>>>   Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>>>   
>>> https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>>>  
>>> 
>>>   Author: Jenkins Build Server >> >
>>>   Date:   2014-10-17 (Fri, 17 Oct 2014)
>>> 
>>>   Changed paths:
>>> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
>>> scripts/script310.st 
>>> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
>>> updates/update40310.st 
>>> M 
>>> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>>> 
>>>   Log Message:
>>>   ---
>>>   40310
>>> 14246 CompiledMethod>>hash can produce clashes
>>> https://pharo.fogbugz.com/f/cases/14246 
>>> 
>>> 
>>> 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core
>>> https://pharo.fogbugz.com/f/cases/14257 
>>> 
>>> 
>>> 14253 MC dependency warning should name which package is failing to load
>>> https://pharo.fogbugz.com/f/cases/14253 
>>> 
>>> 
>>> http://files.pharo.org/image/40/40310.zip 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> --
>>> Marcus Denker  --  den...@acm.org 
>>> http://www.marcusdenker.de 
>> 
> 

Re: [Pharo-dev] Context variables?

[Frank Shearar]

Bear in mind that if you do any fancy stack slicing, you will get...
*unexpected* behaviour from DynamicVariable. (See
http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables/
and follow-on links.)

frank

On 15 October 2014 16:34, Camille Teruel  wrote:
> Hi Jeff,
>
> I think you should look at DynamicVariable and ProcessSpecificVariable
> classes. The first one is a read-only while the second is writable.
> You have to subclass these class for each variable you want.
>
> Ex:
> DynamicVariable subclass: #MyVar.
> MyVar value: 4 during: [ MyVar value ]
>
> HTH,
> Camiile
>
>
> On 15 oct. 2014, at 17:09, J.F. Rick  wrote:
>
> I remember there was some discussion on the list about support for variables
> tied to the context rather than to the instance or class. This seems
> particularly useful for a web application where you might want to access the
> request and response from the context. What is the proper name for these
> kind of variables and where can I read about how to use them?
>
> Cheers,
>
> Jeff
>
> --
> Jochen "Jeff" Rick, Ph.D.
> http://www.je77.com/
> Skype ID: jochenrick
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

[Marcus Denker]

> On 17 Oct 2014, at 12:21, Esteban Lorenzano  wrote:
> 
> that means most probably a merge conflict (still not handled by new 
> integrator app). 
> Sorry, I will fix it soon :)
> 

But I wonder why when I merge the not-integrated slices, it claims that there 
is no change?


> Esteban
> 
>> On 17 Oct 2014, at 12:19, Marcus Denker > > wrote:
>> 
>> We will have to revert this.
>> 
>> -> the changes are not there
>> -> yet when I merge the Slice it claims there are no changes.
>> -> So we have to revert.
>> 
>> On Fri, Oct 17, 2014 at 11:56 AM, GitHub > > wrote:
>>   Branch: refs/heads/4.0
>>   Home:   https://github.com/pharo-project/pharo-core 
>> 
>>   Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>>   
>> https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>>  
>> 
>>   Author: Jenkins Build Server > >
>>   Date:   2014-10-17 (Fri, 17 Oct 2014)
>> 
>>   Changed paths:
>> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
>> scripts/script310.st 
>> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
>> updates/update40310.st 
>> M 
>> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>> 
>>   Log Message:
>>   ---
>>   40310
>> 14246 CompiledMethod>>hash can produce clashes
>> https://pharo.fogbugz.com/f/cases/14246 
>> 
>> 
>> 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core
>> https://pharo.fogbugz.com/f/cases/14257 
>> 
>> 
>> 14253 MC dependency warning should name which package is failing to load
>> https://pharo.fogbugz.com/f/cases/14253 
>> 
>> 
>> http://files.pharo.org/image/40/40310.zip 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> --
>> Marcus Denker  --  den...@acm.org 
>> http://www.marcusdenker.de 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

[Esteban Lorenzano]

that means most probably a merge conflict (still not handled by new integrator 
app). 
Sorry, I will fix it soon :)

Esteban

> On 17 Oct 2014, at 12:19, Marcus Denker  wrote:
> 
> We will have to revert this.
> 
> -> the changes are not there
> -> yet when I merge the Slice it claims there are no changes.
> -> So we have to revert.
> 
> On Fri, Oct 17, 2014 at 11:56 AM, GitHub  > wrote:
>   Branch: refs/heads/4.0
>   Home:   https://github.com/pharo-project/pharo-core 
> 
>   Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>   
> https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>  
> 
>   Author: Jenkins Build Server  >
>   Date:   2014-10-17 (Fri, 17 Oct 2014)
> 
>   Changed paths:
> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
> scripts/script310.st 
> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
> updates/update40310.st 
> M 
> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
> 
>   Log Message:
>   ---
>   40310
> 14246 CompiledMethod>>hash can produce clashes
> https://pharo.fogbugz.com/f/cases/14246 
> 
> 
> 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core
> https://pharo.fogbugz.com/f/cases/14257 
> 
> 
> 14253 MC dependency warning should name which package is failing to load
> https://pharo.fogbugz.com/f/cases/14253 
> 
> 
> http://files.pharo.org/image/40/40310.zip 
> 
> 
> 
> 
> 
> 
> -- 
> --
> Marcus Denker  --  den...@acm.org 
> http://www.marcusdenker.de 

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

[Marcus Denker]

We will have to revert this.

-> the changes are not there
-> yet when I merge the Slice it claims there are no changes.
-> So we have to revert.

On Fri, Oct 17, 2014 at 11:56 AM, GitHub  wrote:

>   Branch: refs/heads/4.0
>   Home:   https://github.com/pharo-project/pharo-core
>   Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>
> https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502aca8caacaac75dc1db
>   Author: Jenkins Build Server 
>   Date:   2014-10-17 (Fri, 17 Oct 2014)
>
>   Changed paths:
> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/
> script310.st
> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/
> update40310.st
> M
> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>
>   Log Message:
>   ---
>   40310
> 14246 CompiledMethod>>hash can produce clashes
> https://pharo.fogbugz.com/f/cases/14246
>
> 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core
> https://pharo.fogbugz.com/f/cases/14257
>
> 14253 MC dependency warning should name which package is failing to load
> https://pharo.fogbugz.com/f/cases/14253
>
> http://files.pharo.org/image/40/40310.zip
>
>
>


-- 
--
Marcus Denker  --  den...@acm.org
http://www.marcusdenker.de

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Marcus Denker]

-- 
Marcus Denker
Sent with Airmail

On 17 Oct 2014 at 11:45:23, Max Leske (maxle...@gmail.com) wrote:


> On 17.10.2014, at 11:39, Sven Van Caekenberghe  wrote:  
>  
>  
> On 17 Oct 2014, at 11:12, Tudor Girba  wrote:  
>  
>> Exactly. So, the problem with Set is not in hash at all, but in equality. Of 
>> course, we can still enhance hash, but we should first focus on equality.  
>>  
>> And I am also of the opinion that equality should take the name of the 
>> selector and even the name of the class into account.  
>  
> From a modelling standpoint it sounds as if one object (CompiledMethod) is 
> used for two different things which results in the conflicting ideas about 
> implementing equality and hashing. A CompiledMethod should hold a 
> CompiledCode object while adding the selector and class. The CompiledCode 
> object could then be equivalent or even be optionally shared among similar 
> methods (like all those implementing ^self).  
>  
> Just an external observation / idea.  

Yes, pretty much what I was thinking. I don’t know what the consequences would 
be for the VM though...  

Yes, I think, too, that many of the problems with CompiledMethod come from the 
fact that we “abuse” a low level object in a context where people
want a higher level concept.

Marcus

Re: [Pharo-dev] [Pharo-users] [Ann] Phratch 4.0

[Tudor Girba]

This is a great addition to the Pharo ecosystem.

Thank you very much!

Doru

On Fri, Oct 17, 2014 at 11:48 AM, jannik laval 
wrote:

> Phratch 4.0 is out of the box !
>
> Phratch 4.0 is cleaner, faster and more stable than phratch 3.0.
>
> After the version 3.0 that was a release for usability and stability,
> phratch 4.0 is released to prepare the future.
>
> The new features are:
>
> - phratch is more modular, eg having a kernel and lots of addons.
> - cleaning a lot the source code
> - customizable environment
> - each block can be made visible or invisible
> - each category can be made visible or invisible
> - it is possible to add translation for addons with the pragma
>  in the class PhratchTranslator. This make the
> translation more modular.
> - first integration of phratch with the pharo environment. Using the
> pragma at the class side of any class in Pharo make the class visible and
> usable in phratch.
> - There is a lot of things to do with phratch, you are welcome to
> contribute ! The documentation for new features will arrive soon.
>
> See you on phratch.com
>
> --
>
> ~~Jannik Laval~~
> École des Mines de Douai
> Enseignant-chercheur
> http://www.jannik-laval.eu
> http://www.phratch.com
> http://www.approchealpes.info
> http://car.mines-douai.fr/
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db
  
https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502aca8caacaac75dc1db
  Author: Jenkins Build Server 
  Date:   2014-10-17 (Fri, 17 Oct 2014)

  Changed paths:
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script310.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40310.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40310
14246 CompiledMethod>>hash can produce clashes
https://pharo.fogbugz.com/f/cases/14246

14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core
https://pharo.fogbugz.com/f/cases/14257

14253 MC dependency warning should name which package is failing to load
https://pharo.fogbugz.com/f/cases/14253

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

[Pharo-dev] [Ann] Phratch 4.0

[jannik laval]

Phratch 4.0 is out of the box !

Phratch 4.0 is cleaner, faster and more stable than phratch 3.0.

After the version 3.0 that was a release for usability and stability,
phratch 4.0 is released to prepare the future.

The new features are:

- phratch is more modular, eg having a kernel and lots of addons.
- cleaning a lot the source code
- customizable environment
- each block can be made visible or invisible
- each category can be made visible or invisible
- it is possible to add translation for addons with the pragma
 in the class PhratchTranslator. This make the
translation more modular.
- first integration of phratch with the pharo environment. Using the pragma
at the class side of any class in Pharo make the class visible and usable
in phratch.
- There is a lot of things to do with phratch, you are welcome to
contribute ! The documentation for new features will arrive soon.

See you on phratch.com

-- 

~~Jannik Laval~~
École des Mines de Douai
Enseignant-chercheur
http://www.jannik-laval.eu
http://www.phratch.com
http://www.approchealpes.info
http://car.mines-douai.fr/

Re: [Pharo-dev] PharoNOS

[Pavel Krivanek]

Here's the image:
https://drive.google.com/file/d/0BzSsmZhqtUTeaURYRnA0eHgycXM/view?usp=sharing

2014-10-17 11:47 GMT+02:00 Pavel Krivanek :
> Hi,
>
> do you plan to develop it as a plugin? When I played with TinyCore
> Linux and Pharo (using framebuffer), I directly applied required the
> plugins on the filesystem.
>
> -- Pavel
>
> 2014-10-17 11:09 GMT+02:00 Torsten Bergmann :
>> Hi Mike,
>>
>> tried to swap the image using the following procedure:
>>
>> 1. Run the following code to download latest Pharo 4.0
>>
>> ZnClient new
>>url: 'http://files.pharo.org/image/40/latest.zip';
>>downloadTo: '/mnt/universe/pharo-image/latest.zip'.
>> ZipArchive extractAllIn: '/mnt/universe/pharo-image/latest.zip'.
>>
>>and extract to "/mnt/universe/pharo-image/"
>>
>> 2. Now I wanted to change /mnt/universe/image file name
>>to point to the new image. Unfortunately I can not write or 
>> delete/recreate
>>this file from Pharo's file browser.
>>
>> Can you provide the build script for the ISO also on GitHub?
>>
>> Thx
>> T.
>>

Re: [Pharo-dev] PharoNOS

[Denis Kudriashov]

If SqueakNOS wil continued and moved to Pharo this name (PharoNOS) should
be free. Maybe this project should be renamed? PharoLinux?

Anyway great job. I remember many yeas ago squeak had similar project by
some japanese guy

2014-10-17 12:39 GMT+04:00 Rafael Luque :

> Then, PharoNOS does not mean No Operating System, but minimun operating
> system?
>
> A few days ago I answered in this list about  Smalltalk-based unikernels,
> similar to Mirage OS (http://www.openmirage.org/).
>
> Do you think PharoNOS can evolve into this kind of tool?
>
>
>
> 2014-10-17 10:28 GMT+02:00 kilon alios :
>
>> I see, I dont have experience with TinyCore linux, but I do have
>> experience with puppy linux which I really liked and used several times on
>> my older pcs. Interest concept , good work :)
>>
>> Actually puppy linux is similar to what you do, in the sense that it uses
>> its own programming language , genie
>>
>>
>> https://wiki.gnome.org/action/show/Projects/Genie?action=show&redirect=Genie
>>
>> On Fri, Oct 17, 2014 at 10:59 AM, mikefilonov 
>> wrote:
>>
>>> Yes, the idea of PharoNOS is to have the Smalltalk-only environment with
>>> as
>>> little external stuff as possible.
>>>
>>> Current PharoNOS implementation based on TinyCore Linux - the smallest
>>> Linux
>>> distro - in order to have the smallest possible system footprint.
>>>
>>> >Why not just download a small linux distro and install Pharo ?
>>>
>>> Well, basically this what PharoNOS is :)
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://forum.world.st/PharoNOS-tp4784982p4785089.html
>>> Sent from the Pharo Smalltalk Developers mailing list archive at
>>> Nabble.com.
>>>
>>>
>>
>

Re: [Pharo-dev] PharoNOS

[Pavel Krivanek]

Hi,

do you plan to develop it as a plugin? When I played with TinyCore
Linux and Pharo (using framebuffer), I directly applied required the
plugins on the filesystem.

-- Pavel

2014-10-17 11:09 GMT+02:00 Torsten Bergmann :
> Hi Mike,
>
> tried to swap the image using the following procedure:
>
> 1. Run the following code to download latest Pharo 4.0
>
> ZnClient new
>url: 'http://files.pharo.org/image/40/latest.zip';
>downloadTo: '/mnt/universe/pharo-image/latest.zip'.
> ZipArchive extractAllIn: '/mnt/universe/pharo-image/latest.zip'.
>
>and extract to "/mnt/universe/pharo-image/"
>
> 2. Now I wanted to change /mnt/universe/image file name
>to point to the new image. Unfortunately I can not write or delete/recreate
>this file from Pharo's file browser.
>
> Can you provide the build script for the ISO also on GitHub?
>
> Thx
> T.
>

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 11:39, Sven Van Caekenberghe  wrote:
> 
> 
> On 17 Oct 2014, at 11:12, Tudor Girba  wrote:
> 
>> Exactly. So, the problem with Set is not in hash at all, but in equality. Of 
>> course, we can still enhance hash, but we should first focus on equality.
>> 
>> And I am also of the opinion that equality should take the name of the 
>> selector and even the name of the class into account.
> 
> From a modelling standpoint it sounds as if one object (CompiledMethod) is 
> used for two different things which results in the conflicting ideas about 
> implementing equality and hashing. A CompiledMethod should hold a 
> CompiledCode object while adding the selector and class. The CompiledCode 
> object could then be equivalent or even be optionally shared among similar 
> methods (like all those implementing ^self).
> 
> Just an external observation / idea.

Yes, pretty much what I was thinking. I don’t know what the consequences would 
be for the VM though...

> 
>> Doru
>> 
>> On Fri, Oct 17, 2014 at 9:52 AM, Max Leske  wrote:
>> 
>>> On 17.10.2014, at 09:37, Tudor Girba  wrote:
>>> 
>>> But why is Set being affected by hash? Hash is never guaranteed to be 
>>> unique. Set should be affected by equality.
>> 
>> Well, actually it’s both #hash and #=. First the set tries to find a 
>> suitable place for the element using the elements hash. If that place is 
>> already taken it then checks equality. Since the equality definition is 
>> mostly the same (same literals, same byte codes etc.), the second element is 
>> rejected because it’s already in the set.
>> 
>>> 
>>> Doru
>>> 
>>> On Fri, Oct 17, 2014 at 9:34 AM, Max Leske  wrote:
>>> 
 On 17.10.2014, at 02:46, Ben Coman  wrote:
 
 Richard Sargent wrote:
> Eliot Miranda-2 wrote
>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>> richard.sargent@
>>> wrote:
>>> One of the best things about Smalltalk is how easily we can say what we
>>> mean. I think you would be better off creating a method named something
>>> like
>>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>>> change #= to answer the, in my opinion, more sensible "is the same as"
>>> that
>>> we conventionally think of #= meaning.
>>> 
>> But that's the point.  #= has to mean something and having it mean #==
>> isn't useful, so one has to choose some value-based semantic for
>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>> means for some value type is far easier than defining what it might mean
>> for something as complex as a CompiledMethod.  The definition in
>> Squeak/Pharo has been useful to me in implementing a closure-based 
>> system,
>> so I'm unapologetic about the current definition.  It is a good one but 
>> it
>> doesn't preclude defining others.
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't 
> say.
> I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a 
> new
> instance of a CompiledMethod that would, in my opinion, be equal to the 
> one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of 
> #=
> has no such characteristic, since it proclaims a CompiledMethod named #a 
> to
> be equal to one named #z.
 
 @Richard
 
 That doesn't seem to be a good example for what your trying to say.
 Given...
 
 [1] SomeClass>>a "original instance"
^1
 
 [2] SomeClass>>a "recompiled instance"
^1
 
 [3] SomeClass>>z
^1
 
 ...you seem to be saying that its useful to know if [1]=[2],
 but imply that is invalidated by [2]=[3] ?
 
 But [1]=[2] remains true, and just as useful for your example.
 
 
 @Max
 
 I guess to call it a bug, you bumped into a different use case
 where [2]=[3] is problematic. Can you describe that?
>>> 
>>> Well, not problematic. Once you accept that neither selector nor class are 
>>> part of a CompiledMethod it is obvious that two instances with the same 
>>> byte codes produce the same hash.
>>> 
>>> The actual problem is more one of understanding and use. The following code 
>>> answers a collection with the CompiledMethods Collection>>add:, 
>>> Collection>>do: and Collection>>remove:ifAbsent:
>>> 
>>> Collection methods select: #isAbstract.
>>> 
>>> All three CompiledMethods are implemented as ‘^ self 
>>> subclassResponsibility’, so they have the same byte codes. Now, if you take 
>>> that collection and make a set out of it you’ll lose Collection>>do: since 
>>> #do: and #add: produ

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 11:12, Tudor Girba  wrote:
> 
> Exactly. So, the problem with Set is not in hash at all, but in equality. Of 
> course, we can still enhance hash, but we should first focus on equality.
> 
> And I am also of the opinion that equality should take the name of the 
> selector and even the name of the class into account.

Did you read Eliot’s argument? He needs the equality definition to find 
duplicates.

I don’t agree with you (anymore). The selector and the class are simply 
associated with a given CompiledMethod. But the CompiledMethod is still one 
without a name and without a class it is installed in. From that point of view, 
neither the class nor the selector should be included in the definition of 
equality.

I do agree however, that it kind of goes against the way programmers tend to 
think of methods, thus my idea (which I did not think through at all) to have 
something like CompiledMethodWrapper, that lets CompiledMethod be what it is 
and abstracts the object for use with class and selector (see my answer to 
Ben’s e-mail).

Cheers,
Max

> 
> Doru
> 
> On Fri, Oct 17, 2014 at 9:52 AM, Max Leske  > wrote:
> 
>> On 17.10.2014, at 09:37, Tudor Girba > > wrote:
>> 
>> But why is Set being affected by hash? Hash is never guaranteed to be 
>> unique. Set should be affected by equality.
> 
> Well, actually it’s both #hash and #=. First the set tries to find a suitable 
> place for the element using the elements hash. If that place is already taken 
> it then checks equality. Since the equality definition is mostly the same 
> (same literals, same byte codes etc.), the second element is rejected because 
> it’s already in the set.
> 
>> 
>> Doru
>> 
>> On Fri, Oct 17, 2014 at 9:34 AM, Max Leske > > wrote:
>> 
>>> On 17.10.2014, at 02:46, Ben Coman >> > wrote:
>>> 
>>> Richard Sargent wrote:
 Eliot Miranda-2 wrote
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
> richard.sargent@
>> wrote:
>> One of the best things about Smalltalk is how easily we can say what we
>> mean. I think you would be better off creating a method named something
>> like
>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>> change #= to answer the, in my opinion, more sensible "is the same as"
>> that
>> we conventionally think of #= meaning.
>> 
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.
 An interesting response. You ignored the point that e.g. #hasSameEffectAs:
 provides greater clarity and add an argument against something I didn't 
 say.
 I also don't think defining equality for a CompiledMethod is particularly
 difficult. If I were to recompile a method's source code, I would get a new
 instance of a CompiledMethod that would, in my opinion, be equal to the one
 already installed in the class (and perhaps cached in the VM's
 optimizations). So one would be able to say that we would not replace an
 existing CompiledMethod with an equal one. The current implementation of #=
 has no such characteristic, since it proclaims a CompiledMethod named #a to
 be equal to one named #z.
>>> 
>>> @Richard
>>> 
>>> That doesn't seem to be a good example for what your trying to say.
>>> Given...
>>> 
>>> [1] SomeClass>>a "original instance"
>>> ^1
>>> 
>>> [2] SomeClass>>a "recompiled instance"
>>> ^1
>>> 
>>> [3] SomeClass>>z
>>> ^1
>>> 
>>> ...you seem to be saying that its useful to know if [1]=[2],
>>> but imply that is invalidated by [2]=[3] ?
>>> 
>>> But [1]=[2] remains true, and just as useful for your example.
>>> 
>>> 
>>> @Max
>>> 
>>> I guess to call it a bug, you bumped into a different use case
>>> where [2]=[3] is problematic. Can you describe that?
>> 
>> Well, not problematic. Once you accept that neither selector nor class are 
>> part of a CompiledMethod it is obvious that two instances with the same byte 
>> codes produce the same hash.
>> 
>> The actual problem is more one of understanding and use. The following code 
>> answers a collection with the CompiledMethods Collection>>add:, 
>> Collection>>do: and Collection>>remove:ifAbsent:
>> 
>> Collection methods select: #isAbstract.
>> 
>> All three CompiledMethods are implemented as ‘^ self 
>> subclassResponsibility’, so they have the same byte codes. Now, if you take 
>> that collect

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Sven Van Caekenberghe]

On 17 Oct 2014, at 11:12, Tudor Girba  wrote:

> Exactly. So, the problem with Set is not in hash at all, but in equality. Of 
> course, we can still enhance hash, but we should first focus on equality.
> 
> And I am also of the opinion that equality should take the name of the 
> selector and even the name of the class into account.

From a modelling standpoint it sounds as if one object (CompiledMethod) is used 
for two different things which results in the conflicting ideas about 
implementing equality and hashing. A CompiledMethod should hold a CompiledCode 
object while adding the selector and class. The CompiledCode object could then 
be equivalent or even be optionally shared among similar methods (like all 
those implementing ^self).

Just an external observation / idea.

> Doru
> 
> On Fri, Oct 17, 2014 at 9:52 AM, Max Leske  wrote:
> 
>> On 17.10.2014, at 09:37, Tudor Girba  wrote:
>> 
>> But why is Set being affected by hash? Hash is never guaranteed to be 
>> unique. Set should be affected by equality.
> 
> Well, actually it’s both #hash and #=. First the set tries to find a suitable 
> place for the element using the elements hash. If that place is already taken 
> it then checks equality. Since the equality definition is mostly the same 
> (same literals, same byte codes etc.), the second element is rejected because 
> it’s already in the set.
> 
>> 
>> Doru
>> 
>> On Fri, Oct 17, 2014 at 9:34 AM, Max Leske  wrote:
>> 
>>> On 17.10.2014, at 02:46, Ben Coman  wrote:
>>> 
>>> Richard Sargent wrote:
 Eliot Miranda-2 wrote
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
> richard.sargent@
>> wrote:
>> One of the best things about Smalltalk is how easily we can say what we
>> mean. I think you would be better off creating a method named something
>> like
>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>> change #= to answer the, in my opinion, more sensible "is the same as"
>> that
>> we conventionally think of #= meaning.
>> 
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.
 An interesting response. You ignored the point that e.g. #hasSameEffectAs:
 provides greater clarity and add an argument against something I didn't 
 say.
 I also don't think defining equality for a CompiledMethod is particularly
 difficult. If I were to recompile a method's source code, I would get a new
 instance of a CompiledMethod that would, in my opinion, be equal to the one
 already installed in the class (and perhaps cached in the VM's
 optimizations). So one would be able to say that we would not replace an
 existing CompiledMethod with an equal one. The current implementation of #=
 has no such characteristic, since it proclaims a CompiledMethod named #a to
 be equal to one named #z.
>>> 
>>> @Richard
>>> 
>>> That doesn't seem to be a good example for what your trying to say.
>>> Given...
>>> 
>>> [1] SomeClass>>a "original instance"
>>> ^1
>>> 
>>> [2] SomeClass>>a "recompiled instance"
>>> ^1
>>> 
>>> [3] SomeClass>>z
>>> ^1
>>> 
>>> ...you seem to be saying that its useful to know if [1]=[2],
>>> but imply that is invalidated by [2]=[3] ?
>>> 
>>> But [1]=[2] remains true, and just as useful for your example.
>>> 
>>> 
>>> @Max
>>> 
>>> I guess to call it a bug, you bumped into a different use case
>>> where [2]=[3] is problematic. Can you describe that?
>> 
>> Well, not problematic. Once you accept that neither selector nor class are 
>> part of a CompiledMethod it is obvious that two instances with the same byte 
>> codes produce the same hash.
>> 
>> The actual problem is more one of understanding and use. The following code 
>> answers a collection with the CompiledMethods Collection>>add:, 
>> Collection>>do: and Collection>>remove:ifAbsent:
>> 
>> Collection methods select: #isAbstract.
>> 
>> All three CompiledMethods are implemented as ‘^ self 
>> subclassResponsibility’, so they have the same byte codes. Now, if you take 
>> that collection and make a set out of it you’ll lose Collection>>do: since 
>> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because 
>> the number of arguments is calculated into the hash (actually the 
>> CompiledMethod header is).
>> 
>> So, as long as you think of CompiledMethods as objects that have a name, it 
>> looks like a bug and in my opinion this behaviour is something that messes 
>> with the m

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Tudor Girba]

Exactly. So, the problem with Set is not in hash at all, but in equality.
Of course, we can still enhance hash, but we should first focus on equality.

And I am also of the opinion that equality should take the name of the
selector and even the name of the class into account.

Doru

On Fri, Oct 17, 2014 at 9:52 AM, Max Leske  wrote:

>
> On 17.10.2014, at 09:37, Tudor Girba  wrote:
>
> But why is Set being affected by hash? Hash is never guaranteed to be
> unique. Set should be affected by equality.
>
>
> Well, actually it’s both #hash and #=. First the set tries to find a
> suitable place for the element using the elements hash. If that place is
> already taken it then checks equality. Since the equality definition is
> mostly the same (same literals, same byte codes etc.), the second element
> is rejected because it’s already in the set.
>
>
> Doru
>
> On Fri, Oct 17, 2014 at 9:34 AM, Max Leske  wrote:
>
>>
>> On 17.10.2014, at 02:46, Ben Coman  wrote:
>>
>> Richard Sargent wrote:
>>
>> Eliot Miranda-2 wrote
>>
>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>>
>> richard.sargent@
>>
>> wrote:
>> One of the best things about Smalltalk is how easily we can say what we
>> mean. I think you would be better off creating a method named something
>> like
>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>> change #= to answer the, in my opinion, more sensible "is the same as"
>> that
>> we conventionally think of #= meaning.
>>
>> But that's the point.  #= has to mean something and having it mean #==
>> isn't useful, so one has to choose some value-based semantic for
>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>> means for some value type is far easier than defining what it might mean
>> for something as complex as a CompiledMethod.  The definition in
>> Squeak/Pharo has been useful to me in implementing a closure-based system,
>> so I'm unapologetic about the current definition.  It is a good one but it
>> doesn't preclude defining others.
>>
>> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
>> provides greater clarity and add an argument against something I didn't
>> say.
>> I also don't think defining equality for a CompiledMethod is particularly
>> difficult. If I were to recompile a method's source code, I would get a
>> new
>> instance of a CompiledMethod that would, in my opinion, be equal to the
>> one
>> already installed in the class (and perhaps cached in the VM's
>> optimizations). So one would be able to say that we would not replace an
>> existing CompiledMethod with an equal one. The current implementation of
>> #=
>> has no such characteristic, since it proclaims a CompiledMethod named #a
>> to
>> be equal to one named #z.
>>
>>
>> @Richard
>>
>> That doesn't seem to be a good example for what your trying to say.
>> Given...
>>
>> [1] SomeClass>>a "original instance"
>> ^1
>>
>> [2] SomeClass>>a "recompiled instance"
>> ^1
>>
>> [3] SomeClass>>z
>> ^1
>>
>> ...you seem to be saying that its useful to know if [1]=[2],
>> but imply that is invalidated by [2]=[3] ?
>>
>> But [1]=[2] remains true, and just as useful for your example.
>>
>>
>> @Max
>>
>> I guess to call it a bug, you bumped into a different use case
>> where [2]=[3] is problematic. Can you describe that?
>>
>>
>> Well, not problematic. Once you accept that neither selector nor class
>> are part of a CompiledMethod it is obvious that two instances with the same
>> byte codes produce the same hash.
>>
>> The actual problem is more one of understanding and use. The following
>> code answers a collection with the CompiledMethods Collection>>add:,
>> Collection>>do: and Collection>>remove:ifAbsent:
>>
>> Collection methods select: #isAbstract.
>>
>>
>> All three CompiledMethods are implemented as ‘^ self
>> subclassResponsibility’, so they have the same byte codes. Now, if you take
>> that collection and make a set out of it you’ll lose Collection>>do: since
>> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because
>> the number of arguments is calculated into the hash (actually the
>> CompiledMethod header is).
>>
>> So, as long as you think of CompiledMethods as objects that have a name,
>> it looks like a bug and in my opinion this behaviour is something that
>> messes with the mind of newcomers. Just a (silly) idea: something like a
>> CompiledMethodWrapper might solve the problem (at least from the user
>> perspective; everything is slightly different from the VM perspective :) ),
>> as it could hold on to the class and the selector independently of the
>> actual CompiledMethod.
>>
>> In the end however, one doesn’t work with compiled methods a lot and the
>> hash situation is unlikely to cause a lot of problems (people working with
>> CompiledMethod usually know what they are doing).
>>
>> Cheers,
>> Max
>>
>>
>>
>> cheers -ben
>>
>>
>> The blue book say #= means "Answer whether the receiver and the argument
>> represent 

Re: [Pharo-dev] PharoNOS

[Torsten Bergmann]

Hi Mike,

tried to swap the image using the following procedure:

1. Run the following code to download latest Pharo 4.0

ZnClient new
   url: 'http://files.pharo.org/image/40/latest.zip';
   downloadTo: '/mnt/universe/pharo-image/latest.zip'.
ZipArchive extractAllIn: '/mnt/universe/pharo-image/latest.zip'.

   and extract to "/mnt/universe/pharo-image/"

2. Now I wanted to change /mnt/universe/image file name
   to point to the new image. Unfortunately I can not write or delete/recreate
   this file from Pharo's file browser.

Can you provide the build script for the ISO also on GitHub?

Thx
T.

Re: [Pharo-dev] OrderedDictionary and new tools, Seaside...

[Sven Van Caekenberghe]

On 16 Oct 2014, at 15:01, Marcus Denker  wrote:

>> 
>> On 16 Oct 2014, at 14:55, p...@highoctane.be wrote:
>> 
>> I am using OrderedDictionary in quite a few places.
>> 
>> Now, I have to steam a lot of extra methods from Dictionary as the 
>> GTInspector doesn't display things properly, nor the WAInspector and its 
>> subclasses out of the box.
>> NeoJSON same story, as Ston etc.
>> 
>> OrderPreservingDictionary is quite useful.
>> Yes, there is GRSmallDictionary but it also has the same issues.
>> 
>> OrderPreservingDictionary is at least a Collection where GRSmallDictionary 
>> is a GRObject.
>> 
>> What would be the best strategy here?
>> 
>> We need such an ordered map all the time, it deserves a bit better.
>> 
>> Opinions?
>> 
> 
> In Pharo4, I copied OrderPreservingDictionary to OrderedDictionary.
> (to have a default one in the image without disturbing clients of 
> OrderPreservingDictionary)
> 
> This should be improved if it something is missing.
> 
>   Marcus

https://pharo.fogbugz.com/f/cases/14260/Add-gt-inspector-views-to-Ordered-Identity-Dictionary

Re: [Pharo-dev] PharoNOS

[Rafael Luque]

Then, PharoNOS does not mean No Operating System, but minimun operating
system?

A few days ago I answered in this list about  Smalltalk-based unikernels,
similar to Mirage OS (http://www.openmirage.org/).

Do you think PharoNOS can evolve into this kind of tool?



2014-10-17 10:28 GMT+02:00 kilon alios :

> I see, I dont have experience with TinyCore linux, but I do have
> experience with puppy linux which I really liked and used several times on
> my older pcs. Interest concept , good work :)
>
> Actually puppy linux is similar to what you do, in the sense that it uses
> its own programming language , genie
>
>
> https://wiki.gnome.org/action/show/Projects/Genie?action=show&redirect=Genie
>
> On Fri, Oct 17, 2014 at 10:59 AM, mikefilonov 
> wrote:
>
>> Yes, the idea of PharoNOS is to have the Smalltalk-only environment with
>> as
>> little external stuff as possible.
>>
>> Current PharoNOS implementation based on TinyCore Linux - the smallest
>> Linux
>> distro - in order to have the smallest possible system footprint.
>>
>> >Why not just download a small linux distro and install Pharo ?
>>
>> Well, basically this what PharoNOS is :)
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/PharoNOS-tp4784982p4785089.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>

Re: [Pharo-dev] PharoNOS

[kilon alios]

I see, I dont have experience with TinyCore linux, but I do have experience
with puppy linux which I really liked and used several times on my older
pcs. Interest concept , good work :)

Actually puppy linux is similar to what you do, in the sense that it uses
its own programming language , genie

https://wiki.gnome.org/action/show/Projects/Genie?action=show&redirect=Genie

On Fri, Oct 17, 2014 at 10:59 AM, mikefilonov  wrote:

> Yes, the idea of PharoNOS is to have the Smalltalk-only environment with as
> little external stuff as possible.
>
> Current PharoNOS implementation based on TinyCore Linux - the smallest
> Linux
> distro - in order to have the smallest possible system footprint.
>
> >Why not just download a small linux distro and install Pharo ?
>
> Well, basically this what PharoNOS is :)
>
>
>
> --
> View this message in context:
> http://forum.world.st/PharoNOS-tp4784982p4785089.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] PharoNOS

[mikefilonov]

Yes, the idea of PharoNOS is to have the Smalltalk-only environment with as
little external stuff as possible.

Current PharoNOS implementation based on TinyCore Linux - the smallest Linux
distro - in order to have the smallest possible system footprint.

>Why not just download a small linux distro and install Pharo ?

Well, basically this what PharoNOS is :)



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

Re: [Pharo-dev] PharoNOS

[Damien Cassou]

On Fri, Oct 17, 2014 at 3:47 AM, mikefilonov  wrote:

> Hm, just now get the idea to run Image chooser if
> default image failed. Is it available on linux?
>

you have the pharo launcher that let's you download images from the web (be
it on jenkins, on files.pharo.org, or on your own server)


-- 
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] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 09:37, Tudor Girba  wrote:
> 
> But why is Set being affected by hash? Hash is never guaranteed to be unique. 
> Set should be affected by equality.

Well, actually it’s both #hash and #=. First the set tries to find a suitable 
place for the element using the elements hash. If that place is already taken 
it then checks equality. Since the equality definition is mostly the same (same 
literals, same byte codes etc.), the second element is rejected because it’s 
already in the set.

> 
> Doru
> 
> On Fri, Oct 17, 2014 at 9:34 AM, Max Leske  > wrote:
> 
>> On 17.10.2014, at 02:46, Ben Coman > > wrote:
>> 
>> Richard Sargent wrote:
>>> Eliot Miranda-2 wrote
 On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
 richard.sargent@
> wrote:
> One of the best things about Smalltalk is how easily we can say what we
> mean. I think you would be better off creating a method named something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as"
> that
> we conventionally think of #= meaning.
> 
 But that's the point.  #= has to mean something and having it mean #==
 isn't useful, so one has to choose some value-based semantic for
 CompiledMethod>>#= and the one that's there is useful.  Defining what #=
 means for some value type is far easier than defining what it might mean
 for something as complex as a CompiledMethod.  The definition in
 Squeak/Pharo has been useful to me in implementing a closure-based system,
 so I'm unapologetic about the current definition.  It is a good one but it
 doesn't preclude defining others.
>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
>>> provides greater clarity and add an argument against something I didn't say.
>>> I also don't think defining equality for a CompiledMethod is particularly
>>> difficult. If I were to recompile a method's source code, I would get a new
>>> instance of a CompiledMethod that would, in my opinion, be equal to the one
>>> already installed in the class (and perhaps cached in the VM's
>>> optimizations). So one would be able to say that we would not replace an
>>> existing CompiledMethod with an equal one. The current implementation of #=
>>> has no such characteristic, since it proclaims a CompiledMethod named #a to
>>> be equal to one named #z.
>> 
>> @Richard
>> 
>> That doesn't seem to be a good example for what your trying to say.
>> Given...
>> 
>> [1] SomeClass>>a "original instance"
>>  ^1
>> 
>> [2] SomeClass>>a "recompiled instance"
>>  ^1
>> 
>> [3] SomeClass>>z
>>  ^1
>> 
>> ...you seem to be saying that its useful to know if [1]=[2],
>> but imply that is invalidated by [2]=[3] ?
>> 
>> But [1]=[2] remains true, and just as useful for your example.
>> 
>> 
>> @Max
>> 
>> I guess to call it a bug, you bumped into a different use case
>> where [2]=[3] is problematic. Can you describe that?
> 
> Well, not problematic. Once you accept that neither selector nor class are 
> part of a CompiledMethod it is obvious that two instances with the same byte 
> codes produce the same hash.
> 
> The actual problem is more one of understanding and use. The following code 
> answers a collection with the CompiledMethods Collection>>add:, 
> Collection>>do: and Collection>>remove:ifAbsent:
> 
> Collection methods select: #isAbstract.
> 
> All three CompiledMethods are implemented as ‘^ self subclassResponsibility’, 
> so they have the same byte codes. Now, if you take that collection and make a 
> set out of it you’ll lose Collection>>do: since #do: and #add: produce the 
> same hash, but #remove:ifAbsent: doesn’t because the number of arguments is 
> calculated into the hash (actually the CompiledMethod header is).
> 
> So, as long as you think of CompiledMethods as objects that have a name, it 
> looks like a bug and in my opinion this behaviour is something that messes 
> with the mind of newcomers. Just a (silly) idea: something like a 
> CompiledMethodWrapper might solve the problem (at least from the user 
> perspective; everything is slightly different from the VM perspective :) ), 
> as it could hold on to the class and the selector independently of the actual 
> CompiledMethod.
> 
> In the end however, one doesn’t work with compiled methods a lot and the hash 
> situation is unlikely to cause a lot of problems (people working with 
> CompiledMethod usually know what they are doing).
> 
> Cheers,
> Max
> 
>> 
>> 
>> cheers -ben
>> 
>> 
>>> The blue book say #= means "Answer whether the receiver and the argument
>>> represent the same component." The current implementation does so only for
>>> some, in my opinion, counter-intuitive definition of "same component".
>>> --
>>> View this message in context: 
>>> http://forum.world.st/CompiledMethod-hash-can-produce-cla

Re: [Pharo-dev] PharoNOS

[Torsten Bergmann]

> Isn't it what Pharocloud is all about? ;)

Partly because in enterprise environments you may want to run apps
in intranet/own network only.

Bye
T.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Tudor Girba]

But why is Set being affected by hash? Hash is never guaranteed to be
unique. Set should be affected by equality.

Doru

On Fri, Oct 17, 2014 at 9:34 AM, Max Leske  wrote:

>
> On 17.10.2014, at 02:46, Ben Coman  wrote:
>
> Richard Sargent wrote:
>
> Eliot Miranda-2 wrote
>
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>
> richard.sargent@
>
> wrote:
> One of the best things about Smalltalk is how easily we can say what we
> mean. I think you would be better off creating a method named something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as"
> that
> we conventionally think of #= meaning.
>
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.
>
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't
> say.
> I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a new
> instance of a CompiledMethod that would, in my opinion, be equal to the one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of #=
> has no such characteristic, since it proclaims a CompiledMethod named #a to
> be equal to one named #z.
>
>
> @Richard
>
> That doesn't seem to be a good example for what your trying to say.
> Given...
>
> [1] SomeClass>>a "original instance"
> ^1
>
> [2] SomeClass>>a "recompiled instance"
> ^1
>
> [3] SomeClass>>z
> ^1
>
> ...you seem to be saying that its useful to know if [1]=[2],
> but imply that is invalidated by [2]=[3] ?
>
> But [1]=[2] remains true, and just as useful for your example.
>
>
> @Max
>
> I guess to call it a bug, you bumped into a different use case
> where [2]=[3] is problematic. Can you describe that?
>
>
> Well, not problematic. Once you accept that neither selector nor class are
> part of a CompiledMethod it is obvious that two instances with the same
> byte codes produce the same hash.
>
> The actual problem is more one of understanding and use. The following
> code answers a collection with the CompiledMethods Collection>>add:,
> Collection>>do: and Collection>>remove:ifAbsent:
>
> Collection methods select: #isAbstract.
>
>
> All three CompiledMethods are implemented as ‘^ self
> subclassResponsibility’, so they have the same byte codes. Now, if you take
> that collection and make a set out of it you’ll lose Collection>>do: since
> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because
> the number of arguments is calculated into the hash (actually the
> CompiledMethod header is).
>
> So, as long as you think of CompiledMethods as objects that have a name,
> it looks like a bug and in my opinion this behaviour is something that
> messes with the mind of newcomers. Just a (silly) idea: something like a
> CompiledMethodWrapper might solve the problem (at least from the user
> perspective; everything is slightly different from the VM perspective :) ),
> as it could hold on to the class and the selector independently of the
> actual CompiledMethod.
>
> In the end however, one doesn’t work with compiled methods a lot and the
> hash situation is unlikely to cause a lot of problems (people working with
> CompiledMethod usually know what they are doing).
>
> Cheers,
> Max
>
>
>
> cheers -ben
>
>
> The blue book say #= means "Answer whether the receiver and the argument
> represent the same component." The current implementation does so only for
> some, in my opinion, counter-intuitive definition of "same component".
> --
> View this message in context:
> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

[Esteban Lorenzano]

> On 17 Oct 2014, at 02:40, Ben Coman  wrote:
> 
> Sven Van Caekenberghe wrote:
>> On 16 Oct 2014, at 22:34, Tudor Girba  wrote:
>>> On Thu, Oct 16, 2014 at 10:23 PM, Nicolai Hess  wrote:
>>> I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds 
>>> printIt-popup is good, but sometimes I want exactly that: "print it".
>>> On "Esc", the popup closes , but the code is still selected. Most of the 
>>> time I
>>> want to go on typing, but first I have to unselect the code.
>>> 
>>> Suggestions:
>>> on "Esc" close the popup and unselect the current selection
>>> 
>>> Good point.
>> +1
>>> on "Enter" insert the printIt-result.
>>> 
>>> Indeed, this is something I thought of, too. However, I am not convinced 
>>> that the frequency of needing to insert the result of "print it" warrants a 
>>> shortcut 
> 
> I often have a few lines of snippets listed in a Workspace that I want to 
> compare the results, or copy/paste the lot to some documentation.
> I was thinking of asking for a  icon/button, but inserting as text is a 
> better idea.
> 
>>> that can be so easily use (i.e., Enter can be used also for adding a line). 
>>> Right now, if you want to insert, you do Cmd+c, Esc, Cmd+v.
> 
> I would go for  rather than , since intuitively that keeps you 
> on the same line.

but also enter means “accept” in everybody’s brain (and other tools prefer that 
over space).
anyway, +1 to that… is something that I really miss. 

Esteban

> 
> 
>> I also don't think 'Print It' is not that common, and if you use it you want 
>> the output to be in a comment anyway so the syntax highlighting doesn't make 
>> everything red.
> 
> When the result is inserted, surrounding it by comment quotes is a good idea.
> 
> cheers -ben
> 
> 
>> I also wanted to add that the whole idea of GT-Tools is to do a lot and even 
>> more powerful things based on a few simple concepts.
>> We are currently making lots of small usability changes, which is all good, 
>> but we have to guard the simplicity.
> 
> 

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

> On 17.10.2014, at 02:46, Ben Coman  wrote:
> 
> Richard Sargent wrote:
>> Eliot Miranda-2 wrote
>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>>> richard.sargent@
 wrote:
 One of the best things about Smalltalk is how easily we can say what we
 mean. I think you would be better off creating a method named something
 like
 #hasSameEffectAs: to answer what you are presently using #= to do, and
 change #= to answer the, in my opinion, more sensible "is the same as"
 that
 we conventionally think of #= meaning.
 
>>> But that's the point.  #= has to mean something and having it mean #==
>>> isn't useful, so one has to choose some value-based semantic for
>>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>>> means for some value type is far easier than defining what it might mean
>>> for something as complex as a CompiledMethod.  The definition in
>>> Squeak/Pharo has been useful to me in implementing a closure-based system,
>>> so I'm unapologetic about the current definition.  It is a good one but it
>>> doesn't preclude defining others.
>> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
>> provides greater clarity and add an argument against something I didn't say.
>> I also don't think defining equality for a CompiledMethod is particularly
>> difficult. If I were to recompile a method's source code, I would get a new
>> instance of a CompiledMethod that would, in my opinion, be equal to the one
>> already installed in the class (and perhaps cached in the VM's
>> optimizations). So one would be able to say that we would not replace an
>> existing CompiledMethod with an equal one. The current implementation of #=
>> has no such characteristic, since it proclaims a CompiledMethod named #a to
>> be equal to one named #z.
> 
> @Richard
> 
> That doesn't seem to be a good example for what your trying to say.
> Given...
> 
> [1] SomeClass>>a "original instance"
>   ^1
> 
> [2] SomeClass>>a "recompiled instance"
>   ^1
> 
> [3] SomeClass>>z
>   ^1
> 
> ...you seem to be saying that its useful to know if [1]=[2],
> but imply that is invalidated by [2]=[3] ?
> 
> But [1]=[2] remains true, and just as useful for your example.
> 
> 
> @Max
> 
> I guess to call it a bug, you bumped into a different use case
> where [2]=[3] is problematic. Can you describe that?

Well, not problematic. Once you accept that neither selector nor class are part 
of a CompiledMethod it is obvious that two instances with the same byte codes 
produce the same hash.

The actual problem is more one of understanding and use. The following code 
answers a collection with the CompiledMethods Collection>>add:, Collection>>do: 
and Collection>>remove:ifAbsent:

Collection methods select: #isAbstract.

All three CompiledMethods are implemented as ‘^ self subclassResponsibility’, 
so they have the same byte codes. Now, if you take that collection and make a 
set out of it you’ll lose Collection>>do: since #do: and #add: produce the same 
hash, but #remove:ifAbsent: doesn’t because the number of arguments is 
calculated into the hash (actually the CompiledMethod header is).

So, as long as you think of CompiledMethods as objects that have a name, it 
looks like a bug and in my opinion this behaviour is something that messes with 
the mind of newcomers. Just a (silly) idea: something like a 
CompiledMethodWrapper might solve the problem (at least from the user 
perspective; everything is slightly different from the VM perspective :) ), as 
it could hold on to the class and the selector independently of the actual 
CompiledMethod.

In the end however, one doesn’t work with compiled methods a lot and the hash 
situation is unlikely to cause a lot of problems (people working with 
CompiledMethod usually know what they are doing).

Cheers,
Max

> 
> 
> cheers -ben
> 
> 
>> The blue book say #= means "Answer whether the receiver and the argument
>> represent the same component." The current implementation does so only for
>> some, in my opinion, counter-intuitive definition of "same component".
>> --
>> View this message in context: 
>> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

[Esteban Lorenzano]

> On 16 Oct 2014, at 22:58, Torsten Bergmann  wrote:
> 
> Tudor wrote:
>> Indeed. This was a discussion I wanted to spawn as well. I would prefer to 
>> change the name from Workspace to Playground in the World Menu. The reason 
>> is >that the Playground is such a distinct departure from the Workspace that 
>> it deserves a different name.
> 
> I do not think it is a departure from the Workspace concept. 
> 
> Therefore I would keep "Workspace" for the menu item name and the window 
> name. It would be enough if the initial 
> tab is called "Playground" because one can play in the code pane (or do 
> serious stuff). 
> 
> This way we would keep up with a known concept (also from other IDE's), it 
> meets what people would expect and 
> no books would have to be rewritten ;)
> 
> BTW: Squeak had a goodie with something similar back in the days (cant 
> remember the name). It was neat as one
> could assemble different objects and different object representations in 
> one navigateable window.
> 
> 
>>> I would suggest to use the well known order "Cut","Copy","Paste".
>> Thanks for noticing. This will be fixed.
> 
> Thanks!
>   
>> Indeed, we had a debate about the name. I proposed the solution 3b you 
>> mention, but it was decided 
>> that it would be too confusing to change the Cmd+i action at this time, and 
>> we chose "Go" to be 
>> the name of the action that is mapped on Cmd+g. 
> 
> Here we agree - I would have choosen 3b as well. Decided by whom? Did I miss 
> the discussion in the
> list or was it offlist?

basically, it was decided by me (and the course of the actions… I did not 
forced anyone :P). 
My reasons remain but I have to say:

1) Survey reflected a clear position towards what now is called 3b
2) We are still making tests… nothing is written in stone and we are looking 
for better ways to do things… so that can change again (and again, and again, 
and like that until we are happy)

> 
>>> ...icons... 
>> This is a known issue and we will look at it soon.
>  
> Sounds good.
>  
>> At the moment, GT is an external project and the contributions should happen 
>> directly in its repository.
> 
> Then please add me to the repo. Still the process is unclear - will I still 
> provide a slice with
> issue number or will I change the config. 
> 
> It is not very lucky that this process was started (without 
> discussion/announcement/description first
> and only for specific packages).  
> 
> Thx
> T.
> 

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

[Esteban Lorenzano]

> On 16 Oct 2014, at 21:01, p...@highoctane.be wrote:
> 
> I'd like to have the old workspace as it is for quick commands and as a kind 
> of CLI where I do not need all the noise of the right part of the playground.
> 
> And the playground for what it is meant to do.
> 
> These two things are *not* for the same use case.

yes, they should. 
If they are not then we have an error somewhere. Could you elaborate a bit on 
why they are not fulfilling same usecase for you?

cheers, 
Esteban

ps: In the future (not in pharo4, certainly), old workspace and inspectors will 
be removed from environment, so we need to make sure the new ones can do the 
job correctly. 

> 
> 
> ​Phil

Re: [Pharo-dev] PharoNOS

[kilon alios]

so the advantage of using this is that is a slim down linux distro with
Pharo included ? Why not just download a small linux distro and install
Pharo ?



On Fri, Oct 17, 2014 at 10:14 AM, mikefilonov  wrote:

> Thank you Torsten. Great ideas :) I made a to-do list for this project not
> to
> forget anything
> https://trello.com/b/JXtcf2Ye/pharonos
>
> >Yes, I have the following quick setup scenario in mind: downlod the ISO,
> start a virtual computer
> >with it (in virtualization software or on a cloud server). Use the Pharo
> based setup wizard (see above)
> >to setup keyboard layout, give a fixed IP, adjust the clock, ...
> >and download a premade Seaside (or other webframework image) from CI. Now
> run on port 80, configure >another
> >port and give a name to the machine in the network. This way one could
> easily setup virtualized
> >network machines to provide network delivered applications.
>
> Isn't it what Pharocloud is all about? ;)
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/PharoNOS-tp4784982p4785075.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] PharoNOS

[mikefilonov]

Thank you Torsten. Great ideas :) I made a to-do list for this project not to
forget anything 
https://trello.com/b/JXtcf2Ye/pharonos

>Yes, I have the following quick setup scenario in mind: downlod the ISO,
start a virtual computer 
>with it (in virtualization software or on a cloud server). Use the Pharo
based setup wizard (see above) 
>to setup keyboard layout, give a fixed IP, adjust the clock, ... 
>and download a premade Seaside (or other webframework image) from CI. Now
run on port 80, configure >another 
>port and give a name to the machine in the network. This way one could
easily setup virtualized 
>network machines to provide network delivered applications. 

Isn't it what Pharocloud is all about? ;)




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

Re: [Pharo-dev] Mysteries of the compiler

[Eliot Miranda]

On Thu, Oct 16, 2014 at 11:53 PM, Marcus Denker 
wrote:

> On 16 Oct 2014 at 22:07:03, Nicolai Hess (nicolaih...@web.de) wrote:
>
> 2014-10-16 17:40 GMT+02:00 Marcus Denker :
>
>> >>
>> >> While in the write we need to mark:
>> >>
>> >> lookupVariableForWrite: aVariableNode
>> >>
>> >>  | var |
>> >>
>> >>  var := scope lookupVar: aVariableNode name.
>> >>
>> >>  var ifNil: [^var].
>> >>  var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable:
>> aVariableNode ].
>> >>  var isWritable ifFalse: [ self storeIntoReadOnlyVariable:
>> aVariableNode ].
>> >>
>> >>  var isTemp ifTrue: [
>> >>  "when in a loop, all writes escape"
>> >>  scope outerScope isInsideOptimizedLoop ifTrue: [ var
>> markEscapingWrite ].
>> >>  "else only escaping when they will end up in different
>> closures"
>> >>  (var scope outerNotOptimizedScope ~= scope
>> outerNotOptimizedScope)
>> >>  ifTrue: [ var markEscapingWrite]].
>> >>  ^var
>> >>
>> >>
>> >> I checked that all Opal tests that are failing are actually testing
>> wrong, and I double checked
>> >> that all those methods are now compiled like with the old old compiler…
>> >> Now recompilng the image.
>> >
>> > Hmm… nope…. something wrong.
>> >
>>
>> the “outerScope” was wrong.
>>
>> So without that, I can recompile the image and your example is compiled
>> without temp vectors…
>>
>> Marcus
>>
>
> good!
> I'll open an issue on fogbugz and create a slice with your changes.
>
> about reordering of tempvars:
> It would be nice if the order preserves, but I think we can live with it.
>
> Yes, we should order them. But keep in mind that this does not mean that
> you
>
> can access them via “at: index”. The index is “virtual”, so var3 can be
> actually var2,
>
> because the *real* var2 lives together with var1 in a tempVector (which is
> now var1).
>
> Knowledge has to come from somewhere… e.g. the DebuggerMethodMap builds up
>
> a description, while we (for now) just delegate to the AST (+scopes +
> semantic vars).
>
> this means that
>
> #tempAt:
>
> sees always the real world. e.g. a method with 3 vars where they are all
> in the tempVector,
>
> tempAt:2 will raise an error.
>
> namedTempAt: does what the old one did.
>
Not quite.  What namedTempAt:[put:] do is access the temps in the order
they appear in the list answered by ContextPart>>tempNames which is self
debuggerMap tempNamesForContext: self.  This is a flattened list that
includes both direct and indirect temps.  This is also the list that the
Squeak debugger uses to populate the bottom-right context inspector in the
debugger.  namedTempAt:[put:] matches tempAt:[put:] until you get to an
indirect temp.  In a method the Squeak compiler always puts the indirect
temps after all the direct temps, so the two match until the first indirect
temp.  But in a closure the situation is potentially much more complex
because indirection vectors can be part of a closure's copied values, so it
may have any number of indirection vectors copied form outer scopes, its
own local direct temps and its own local indirect temps.  The copied values
get pushed after the arguments and before the local temps.  So the ordering
potentially gets complicated.

This now can get confused in the Opal case with the changing order, which
> we should fix.
>
> (and yes, we should check how much slower the AST bases scheme is for
> accessing
>
> temps by offset... we could cache a representation similar to what the old
> DebuggerMethodMap
>
> does).
>

Or use DebuggerMethodMap, rewriting the code to make it more
comprehensible...  Why reinvent the wheel?


>
> Although there is an issue with the debugger:
> 14058  Inconsistent
> information in debugger
> I solved that one by using tempvar names instead if the index, but
> this has another issue (sometimes the last (or most nested) tempvar is
> always nil).
>
> The real error is, EyeDebuggerContextInspector does recognizes if the
> index changes
> (somewhere in EyeDebuggerContextInspector>>#updateList it
> compares the new elements (with new indices) with the old elements list
> and skips the update)
>
> Ok… that could be fixed with ordered temp names?
>
>   Marcus
>
>
>
>


-- 
best,
Eliot