November 2015 - Pharo-dev - lists.pharo.org

Nice text about the role of (user interface) design

by Stephan Eggermont

Don Norman and Bruce Tognazzini write about beauty and design. I think there are some important lessons and directions in it for us. http://www.fastcodesign.com/3053406/how-apple-is-giving-design-a-bad-name Stephan

Nov. 30, 2015

Re: [Pharo-dev] [Pharo-users] Pharo Consortium New Gold Member: Thales

by Tudor Girba

Great news! For everyone not directly involved in the Consortium: The money collected from memberships go towards the infrastructure of Pharo in form of engineering time. This is a key effort to make Pharo a sustainable platform for the long run. That is why these pieces of news are so important. Doru > On Nov 26, 2015, at 2:42 PM, marcus.denker(a)inria.fr wrote: > > The Pharo Consortium is very happy to announce that Thales > has joined the Consortium as an Gold Member. > > About > - Thales: https://www.thalesgroup.com > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org > -- www.tudorgirba.com "Value is always contextual."

Nov. 30, 2015

Re: [Pharo-dev] Java Future

by Tudor Girba

Hi, Increasing the community is certainly important, and we welcome any action that anyone would want to undertake in this direction. However, talking about the future of Java does not fall in this category. Cheers, Doru > On Nov 30, 2015, at 4:44 AM, EuanM <euanmee(a)gmail.com> wrote: > > We also need to concentrate on building our community. > > We build a better platform faster if we have more people. > > We build a more valuable platform if we have a wider range of valuable > use cases to target. > > Unless and until we hit a critical mass of people joining our > community, we *need* to spend some of our focus on community-building. > > Part of great is being able to build things to sufficient completeness > *and* keep them in working order over the long haul. This is easier > with more contributors. > > On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hello everyone, >> >> Please stop this thread on this mailing list. We need to focus on building a great platform. >> >> Cheers, >> Doru >> >> >>> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >>> >>> First of all - is this true? Where can we read about it? >>> >>> I cannot find anything about this at >>> https://www.oracle.com/search/press >>> >>> ======================================= >>> >>> If Oracle did make this statement, then what people have said so far >>> is true. BUT... >>> >>> Java got about 40% of its initial momentum from IBM dumping VisualAge >>> and putting all their resources into Java. >>> >>> Oracle are targetting this move at IBM more than anyone else. >>> >>> IBM will start to think about how to migrate from Java - as Oracle are >>> telling them they will have to. (It's OUR bat and its OUR ball, and >>> no-one else can play with it. Not even the Java Community). And >>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >>> expect the licence-fee income for JREs is small. >>> >>> Oracle are doing one of two things - announcing that Java is for sale >>> to device providers - phones (Google is the obvious buyer) or the >>> impending Internet of Things (which was what Java was designed for >>> originally) or announcing that no-one making an internet of things >>> offering should consider Java. >>> >>> Yes, things live on and on in a kind of zombie state. So yes, things >>> live on as long as their ecosystem does. And they gently wither and >>> their ecosystem withers is a long slow drawn out spiral. Which is why >>> we still have Cobol. >>> >>> People and organisations tend to move from one technology to another >>> in an incremental fashion. Swapping a little bit here, and a little >>> bit there. >>> >>> The new target platforms are ones which >>> 1) look like they have longevity, and >>> 2) have a migration pathway that provides incremental steps. >>> >>> Offering a compelling advantage is good - but only if the steps 1) >>> and 2) are catered to. >>> >>> IBM VisualAge Smalltalk is still robust, commercially available >>> software, and VisualStudio and Gemstone continue to represent >>> Smalltalk out to the big world of corporate development. >>> >>> So that's a start. >>> >>> Say only 5% of the Java world moves away from Java each year, as a >>> result of this announcement. >>> >>> We *should* wish to take advantage of this announcement. >>> >>> After all, think what difference having even 0.01% of the world's Java >>> coders moving to Smalltalk would make. How could we help that >>> happen? >>> >>> Think what it would be like to have thought-leaders like Kent Beck and >>> Ward Cunningham back in the Smalltalk fold. How could we help that >>> happen? >>> >>> Think what it would be like to get back all the universities who moved >>> from teaching OO concepts using Smalltalk into teaching them via Java. >>> We now know almost all the ones using Smalltalk as a teaching language >>> by name. Does anyone know even how many universities teach OO via >>> Java? What would it be like if 5% of those universities moved to >>> Smalltalk each year. How could we help that happen? >>> >>> Next - do we have any big brained thinkers who can see specific ways >>> we can improve interoperation between Java facilities and libraries >>> and the Smalltalks? For the next 12 months, we should work on Java >>> integration, rather than C++ integration. We should identify the >>> three best things for us to do in this regard, and make them polished >>> and compelling. Who is in a position to help that happen? >>> >>> The final way we can take advantage help the maximum number of people >>> find their way to us is to present a united community front to the >>> outside world. In the same way I am both a European and a Scot, we >>> need to be Smalltalkers *and*members of our individual >>> Smalltalk-platform communities. >>> >>> How can we help make that happen? >>> >>> This is not a silver bullet. It's going to cause a long-term trend in >>> events, not a sudden abrupt change. But it will have a real, if >>> gradual effect. (assuming that >>> >>> Equally, it is not something we should ignore. It is something we >>> should make use of. We need to put effort into raising our profile >>> over the next 6 months. >>> >>> On 25 November 2015 at 19:51, Casimiro - GMAIL >>> <casimiro.barreto(a)gmail.com> wrote: >>>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: >>>> >>>> >>>> >>>> On 25/11/2015 19:55, Jimmie Houchin wrote: >>>> >>>> Much truth in what you say. However, what Oracle choose to invest its money, >>>> time, personnel resource into Java does affect its present and future. It >>>> has a great affect. But it isn't the whole story. Java has enough momentum >>>> in what already exists in the language and vm and what has been release >>>> under its license, for businesses to keep going for some time with only what >>>> currently exists. >>>> >>>> Cobol is still alive (and well) after > 50 years. >>>> You can expect Java programmers to find jobs for many years yet to come >>>> :-) >>>> >>>> nicolas >>>> >>>> -- >>>> Nicolas Anquetil >>>> RMod team -- Inria Lille >>>> >>>> 1st: Java is extremely profitable. Each android phone, each android TV, each >>>> android embedded system pays copyrights to Oracle. >>>> 2nd: Much of current cloud infrastructure depends on java. >>>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will continue >>>> to be used by same reasons these languages are used. >>>> >>>> IMHO, discussing java is not profitable. Better to discuss things to be than >>>> talk about things that already happened. >>>> >>>> casimiro >>>> >>>> -- >>>> The information contained in this message is confidential and intended to >>>> the recipients specified in the headers. If you received this message by >>>> error, notify the sender immediately. The unauthorized use, disclosure, copy >>>> or alteration of this message are strictly forbidden and subjected to civil >>>> and criminal sanctions. >>>> >>>> == >>>> >>>> This email may be signed using PGP key ID: 0x4134A417 >>> >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> > -- www.tudorgirba.com "Presenting is storytelling."

Nov. 30, 2015

Re: [Pharo-dev] what happened to the monkey

by Christophe Demarey

jenkins slaves connection were lost. I restarted Jenkins and everything looks ok now. Le 30 nov. 2015 Ã 11:06, Nicolai Hess a Ã©crit : > no issue validation since last weekend.

Nov. 30, 2015

Re: [Pharo-dev] what happened to the monkey

by Marcus Denker

Hello, The whole CI setup was in such a strange state saturday that it looked like it needed a reboot of all slaves or even more likely intervention of the admins. I decided to postpone to Monday looking into it. It seems it is up and running again now. Marcus > On 30 Nov 2015, at 07:06, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > no issue validation since last weekend.

Nov. 30, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 30, 2015

[pharo-project/pharo-core] a6d83d: 50477

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a6d83d28de549e5e0bfb948f07fa983453d0b5dd https://github.com/pharo-project/pharo-core/commit/a6d83d28de549e5e0bfb948f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-30 (Mon, 30 Nov 2015) Changed paths: A FontInfrastructure.package/LogicalFont.class/instance/accessing/lineGrid.st A FreeType.package/FreeTypeFont.class/instance/accessing/familyName.st M NECompletion.package/NECPreferences.class/class/accessing/overrideModel_.st R Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/iconLabel.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50476.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50477.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50476.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50477.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Examples.package/DynamicWidgetChange.class/instance/private/change.st A Spec-Examples.package/TabsExample.class/instance/accessing/title.st R Spec-Examples.package/TabsExample.class/instance/as yet unclassified/title.st M Spec-Examples.package/TabsExample.class/instance/initialization/populateManager.st A Spec-Examples.package/TabsExample.class/instance/private/dynamicTab.st Log Message: ----------- 50477 16555 Correct and Improve Spec example DynamicWidgetChange https://pharo.fogbugz.com/f/cases/16555 17161 Missing subclass responsibility implementation in some Font subclasses https://pharo.fogbugz.com/f/cases/17161 17157 preference for completing whole methods can not be enabled https://pharo.fogbugz.com/f/cases/17157 17153 BreakpointIconStyler>>#iconLabel is dead code https://pharo.fogbugz.com/f/cases/17153 http://files.pharo.org/image/50/50477.zip

Nov. 30, 2015

Re: [Pharo-dev] red banner and links with safari?

by Stephan Eggermont

On 30-11-15 05:16, EuanM wrote: > A link to Stack Overflow is valuable in lots of ways: > > 1) It is a very good code facility for questions and answers, which is > exceptionally searchable via Google Bing et al. That is not valuable if we cannot provide the answers. On StackOverflow we often cannot provide the answers needed. The amount of time I had to spend getting closed questions reopened makes it a bad platform for us. And remember, SO is not about giving the right answers, it is about giving popular answers. > 2) Why does it matter who hosts the data? > > It is freely and publically available, and Stack Exchange are > well-funded to keep it that way over the long haul. Because we need to think longer term. I regularly need 15 and 20year old information. StackOverflow doesn't look to be making much money and is not owned by a non-profit. That makes it vulnerable to new ownership shutting it down. I agree that for SO the availability of the data is not much of an issue. Ownership is, as we can not publish a digest of interesting questions and answers. > What benefit does owning the data provide? (My general experience is > that trying to control and own data leads to greater data losses over > time, compared to putting them in a well-funded public repository. There is a difference between a private and a public repository. Data losses arise from using proprietary formats that can no longer be reconstructed. Mail, irc and netnews archives are easy to read and keep over time. We already know how to avoid data losses: use peer-to-peer distribution, bittorrent style. > Does the rest of the world use github, or does it builld its own facilities? > We don't own the github data. Github is not our community. That makes depending on github only a bad move. The nice thing about git is that it is properly distributed. > Do we use Slack, or have we built our own? > We don't own the Slack data. Slack is not our community. And that already creates problems. Valuable design discussions are not properly preserved. > 3) We certainly *do* have the possibility to influence the answers. > If we cannot influence answers to Pharo-specific questions on a public > Q&A site, who can? 1000 times as many clueless non-smalltalkers. > 4) Why Stack Overflow? > Going to where there are valuable resources is a good idea. For us, > the most valuable resource is developers. People who develop the > Pharo platform and developers who *use* the Pharo platform. No, it is not. Paid smalltalk projects is much more valuable. We won't get them from answering tech-only questions of new smalltalkers. And let's take a look at what actually is on SO. What message does looking at the smalltalk or pharo tag on SO send to these developers? Who should that convince that developing in Pharo is a smart idea? > At Stack Overflow, we have the opportunity to access the hearts and > minds of a *very* large group of developers. No we don't. At SO we can answer stupid questions requiring no discussion or trade-offs. Everything else is closed. That makes it very difficult to show the advantages of smalltalk. > Stack Overflow is a good way to help us encourage people to express > interest, and possibly even join us. Not really. The first year or so we were able to provide interesting information on SO, and even then we had enormous problems with the clueless majority. Just take a look at questions on OODBs vs relational. Already at that time it was clear that people using popular technology gained reputation much faster than those using non-mainstream/hyped technology. Thereafter, the closing down of everything that required a little thought and discussion and the enormous amount of clueless closers made SO a dying platform. The number of views and answers/question is going down. > Stronger, wider, deeper awareness of the benefits of our platform can > only help interest in using it. SO is not a platform that allows us to do that. Stephan

Nov. 30, 2015

what happened to the monkey

by Nicolai Hess

no issue validation since last weekend.

Nov. 30, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by EuanM

Does git not allow additional attribute objects that it benignly stores and ignores? (I suspect I can guess the answer, but...) On 30 November 2015 at 05:55, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 30 nov. 2015 5:24 AM, "EuanM" <euanmee(a)gmail.com> a Ã©crit : >> >> Is there anything stopping us adding one more dictionary to each >> Monticello commit? >> >> A key of commit ids and values of author name? > > This dictionary is already there in the version metadata... The file that > generates conflicts in git. > > Thierry > >> On 24 November 2015 at 06:55, stepharo <stepharo(a)free.fr> wrote: >> > +1 >> > >> > And so far Monticello is much better that having delta because you can >> > still >> > get a complete project without having to reconstruct the complete >> > snapshot from deltas. I could not imagine the amount of code we would >> > have >> > lost else. >> > Veronica in her PhD built a crawler that reconstructs all the deltas >> > based >> > on MC files. Now this is work. >> > Stef >> > >> > Le 23/11/15 17:02, Nicolas Cellier a Ã©crit : >> > >> > It's not Monticello per se. It's the backend (the server) which is too >> > naive. >> > The .mcz must be considered as a unit of exchange between the server >> > (the >> > repository) and the client (the working copy). And please note that in >> > Monticello, it's not the only way to exchange data, it can also be a >> > .mcd (a >> > diff). >> > >> > Nothing forces the server to store the .mcz as is. That's just a naive >> > implementation. Chris Muller demonstrated how to use a database (magma) >> > as >> > backend... >> > >> > 2015-11-23 12:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >> >> >> >> > On 22 Nov 2015, at 20:12, EuanM <euanmee(a)gmail.com> wrote: >> >> > >> >> > Is there any reason against amending Monticello to store and save all >> >> > author's names? >> >> >> >> It does. *If* you have all the versionsâ¦ but doing anything with âall >> >> the >> >> versionsâ >> >> is so slow (you need to download them, unpack themâ¦) that we do not >> >> even >> >> have >> >> a tool to show the history of a method. >> >> (getting the oldest should be simpler, if you have complete >> >> history+this >> >> .mcz is >> >> there). >> >> >> >> Monticello is meant to be a system to save the complete history of a >> >> project >> >> (if you keep all the MCZ available), but the idea to save every tiny >> >> revision as >> >> a complete snapshot, zip compresses, makes it near impossible to do >> >> anything >> >> with the history in practice. >> >> >> >> With today disks, a practical SCM would allow anyone to have the >> >> *complete* >> >> history on the local disk. Monticello does now allow that in any >> >> practical >> >> way. >> >> >> >> > >> >> > Presumably, we'd also want a tool that could extract amnders' names >> >> > all the way back to the first commit of a package? >> >> > >> >> > How many on-line Monticello repositories are in common use? >> >> > >> >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >> >> > >> >> > Are there active administrators for each of those repositories that >> >> > would allow us to update the repositories to use the updated >> >> > Monticello? >> >> > >> >> > On 22 November 2015 at 15:42, Marcus Denker <marcus.denker(a)inria.fr> >> >> > wrote: >> >> >> >> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk(a)gmail.com> >> >> >> wrote: >> >> >> >> >> >> >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >>> >> >> >>> epicea data is not stored forever. It is seasion based and the >> >> >>> shipped >> >> >>> image is >> >> >>> clean. >> >> >> >> >> >> >> >> >> But current source of this info is changes file (maybe sources). And >> >> >> I >> >> >> remember you planned to store current sources in image. And such >> >> >> information >> >> >> can be there too. >> >> >> Maybe I miss something? >> >> >> >> >> >> >> >> >> The original author is not really that much of information. And >> >> >> storing >> >> >> it >> >> >> for every method in the image would take space. >> >> >> >> >> >> As I said: the whole idea of using a source revision control system >> >> >> is >> >> >> that >> >> >> you have the *complete* history available, but >> >> >> not wasting RAM. >> >> >> >> >> >> Marcus >> >> > >> >> >> >> >> > >> > >>

Nov. 30, 2015