October 2014 - Pharo-dev - lists.pharo.org

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

by 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.

Oct. 18, 2014

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

by Nicolai Hess

2014-10-18 0:38 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > 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?

Oct. 17, 2014

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

by 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 <nicolaihess(a)web.de> wrote: > 2014-10-17 23:43 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> 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. >> >> >

Oct. 17, 2014

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

by Nicolai Hess

2014-10-17 23:43 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > 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. > >

Oct. 17, 2014

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

by Chris Muller

> How about releasing the V3 version as Squeak 4.6, and the Spur version as > Squeak 5.0 at the same time? Yes, that's the way to go! They (4.6 and 5.0) should be "equivalent" with each other -- Everything other than the VM and new restrictions (i.e., 64K restriction) would be the same. That way external apps can "port" to being Spur-compatible without worrying about any other functionality gaps between the two images causing problems. > 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. Yip. > > Levente > >> -- >> best,Eliot >> >

Oct. 17, 2014

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

by 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.

Oct. 17, 2014

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

by 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-tp4784722p478… >> 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-tp4784722p478… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2014

TLS SNI[1] for SqueakSSL on unix

by 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/

Oct. 17, 2014

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

by 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 > <phratchTranslation: âfrâ> 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. >

Oct. 17, 2014

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

by 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 <sven(a)stfx.eu>: > This is excellent news. > > On 15 Oct 2014, at 14:00, Marcus Denker <marcus.denker(a)inria.fr> 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 > >

Oct. 17, 2014