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

[pharo-project/pharo-core] d12673: 50483

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d1267341a42b97e366de51b22cf83e5cb2f1f22a https://github.com/pharo-project/pharo-core/commit/d1267341a42b97e366de51b2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-04 (Fri, 04 Dec 2015) Changed paths: M FontChooser.package/FontChooserMorph.class/instance/interface building/newFontPointSizeField.st M Morphic-Core.package/Morph.class/instance/events-processing/handleMouseMove_.st A Morphic-Core.package/Morph.class/instance/events-processing/handlesMouseMove_.st R Morphic-Widgets-NewList.package/NewListExample.class/README.md R Morphic-Widgets-NewList.package/NewListExample.class/definition.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/accessing/listMorph.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/accessing/listMorph_.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialization/initialize.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/buildMorph.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/buildMorphWithOld.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/buildTextMorph.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/openInWindow.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/openInWorld.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/withNewList.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/initialize/withOldList.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/allowToSelect.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/displayItem_.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/drop_at_.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/getIndex.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/getItems.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/headerTitle.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/iconFor_at_.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/iconMaxSize.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/menu_shifted_.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/setIndex_.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/morphic/title.st R Morphic-Widgets-NewList.package/NewListExample.class/instance/protocol/toggleTitle.st M NECompletion.package/NECContext.class/instance/accessing/createModel.st A NECompletion.package/NECContext.class/instance/private-type-guessing/completionTokenIsComment.st A NECompletion.package/NECContext.class/instance/private-type-guessing/completionTokenIsLiteralOrComment.st M NECompletion.package/NECContext.class/instance/private/createRanges.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50482.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50483.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50482.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50483.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/extension/Behavior/instance/classLayout.st M Slot.package/extension/Behavior/instance/layout.st M Slot.package/extension/Behavior/instance/layout_.st M SmartSuggestions-Tests.package/SugsMockContext.class/instance/api-context/sourceTextArea.st Log Message: ----------- 50483 17167 disable NEC completion in method comments https://pharo.fogbugz.com/f/cases/17167 17181 Rename layout to classLayout (step 3.5 replace implementation in Behavior) https://pharo.fogbugz.com/f/cases/17181 16724 new removal of RubPluggableTextMorph https://pharo.fogbugz.com/f/cases/16724 17178 Move checking logic of #handleMouseMove: into #handlesMouseMove: https://pharo.fogbugz.com/f/cases/17178 http://files.pharo.org/image/50/50483.zip

Dec. 4, 2015

Re: [Pharo-dev] Java Future

by Marcus Denker

We are quite fast in integrating the last weeks (even months). *Reviewed* fixes get integrated within hours, and I try to review as much as I can if others do not. To me this sounds like a fix to some other project on SmalltalkHub. T The thing here is that this is like gitHub: if a random Java project is abandoned, does Oracle step in and take over maintenance? Marcus > On 04 Dec 2015, at 09:49, phil(a)highoctane.be wrote: > > Question: how long to drop the slice into the inbox? > > On Fri, Dec 4, 2015 at 8:51 AM, EuanM <euanmee(a)gmail.com <mailto:euanmee@gmail.com>> wrote: > Hi Steph, > > As a newcomer, here is my experience with my first bug-fix: > > I wrote the fix in about 5 minutes. > > It then took several weeks to get the big-fix accepted because of > issues with the repository and, separately, with bitrot in the list of > maintainers. > > On 30 November 2015 at 16:52, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > True help closing bug > > Build a great library > > Buidl a cool software > > > > Stef > > > > Le 30/11/15 04:44, EuanM a Ã©crit : > > > >> 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 <mailto:tudor@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 <mailto:euanmee@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 <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 <mailto:casimiro.barreto@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 <http://www.tudorgirba.com/> > >>> > >>> "Reasonable is what we are accustomed with." > >>> > >>> > >> > > > > > >

Dec. 4, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Max Leske

I feel you :) Without having thought this through completely: if you look at the implementation of DynamicVariable>>value:during: youâll see that the way it works is that the variable is bound to the active process. In the debugger you have access to the process that is being debugged and thus you should have access to the variables bound to it. You could try accessing all such variables by iterating over them (which I think will require an extension on Process because youâd need to access at least the PSKeys class variable). Cheers, Max > On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi guys, > > This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) > > For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) > > WACurrentRequestContext use: self during: aBlock > > In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. > > So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. > > Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. > > Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? > > Thoughts? > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 4, 2015

Re: [Pharo-dev] Java Future

by phil＠highoctane.be

Question: how long to drop the slice into the inbox? On Fri, Dec 4, 2015 at 8:51 AM, EuanM <euanmee(a)gmail.com> wrote: > Hi Steph, > > As a newcomer, here is my experience with my first bug-fix: > > I wrote the fix in about 5 minutes. > > It then took several weeks to get the big-fix accepted because of > issues with the repository and, separately, with bitrot in the list of > maintainers. > > On 30 November 2015 at 16:52, stepharo <stepharo(a)free.fr> wrote: > > True help closing bug > > Build a great library > > Buidl a cool software > > > > Stef > > > > Le 30/11/15 04:44, EuanM a Ã©crit : > > > >> 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." > >>> > >>> > >> > > > > > >

Dec. 4, 2015

Re: [Pharo-dev] [Moose-dev] MacroRecorder available in Pharo

by Dimitris Chloupis

WOW a pharo video where someone actually speaks, thats rare :D Impressive tool, and certainly useful if you have to do a lot of changes in a lot of code. The name is a bit misleading because its not really a general purpose macro recorder and focused only on transformations. I vaguely remember another macro recorder that was able to macro record and playback any pharo action. On Fri, Dec 4, 2015 at 10:35 AM Gustavo Santos <gugajansen(a)gmail.com> wrote: > Hello guys, > > I would like to present you MacroRecorder, a tool to build custom source > code transformations in Pharo. > > The tool is available in the Catalog for some weeks now. > The current version runs in Pharo 5 and there is an old version running in > Pharo 4. > > To show how this tool works, I prepared a quick demo video. > Take a look: https://youtu.be/gW3l4O-WEGs > > Right now, I'm interested in usage data. > That means, if you face a case of repetitive code transformation in > practice, and I believe this happened to most of you, please: > (i) show me the transformations you did, in case they already happened in > the past, or > (ii) consider using the tool to apply them automatically > > And, of course, feel free to ask questions, provide feedback, etc. > > Kind regards, > > -- > Gustavo Santos > http://gustavojss.github.io/ > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Dec. 4, 2015

MacroRecorder available in Pharo

by Gustavo Santos

Hello guys, I would like to present you MacroRecorder, a tool to build custom source code transformations in Pharo. The tool is available in the Catalog for some weeks now. The current version runs in Pharo 5 and there is an old version running in Pharo 4. To show how this tool works, I prepared a quick demo video. Take a look: https://youtu.be/gW3l4O-WEGs Right now, I'm interested in usage data. That means, if you face a case of repetitive code transformation in practice, and I believe this happened to most of you, please: (i) show me the transformations you did, in case they already happened in the past, or (ii) consider using the tool to apply them automatically And, of course, feel free to ask questions, provide feedback, etc. Kind regards, -- Gustavo Santos http://gustavojss.github.io/

Dec. 4, 2015

Re: [Pharo-dev] VoyageMongo and cache compaction

by Holger Freyther

> On 04 Dec 2015, at 00:16, Ben Coman <btc(a)openinworld.com> wrote: > > I haven't used VoyageMongo, but just a general comment that maybe the > testcase is best produced at your end, since you understand the > symptoms and can cut down a slice of your application as a template. > Publishing that to the mail list provides an explicit demonstration of > the problem making it easier for someone to assist. Indeed, as an > extension if all the steps to load up VoyageMongo and set up the > environment are included, sometimes I'll even be inclined to > investigate such things that are unknown to me as a form of > goal-directed learning (although right I'm now tied up with some other > things). One will need to install a real mongodb to test this and then load VoyageMongo (e.g. through the Configuration Browser) | repo point | repo := VOMongoRepository database: 'cacheIssue'. 1 to: 100 do: [:each | point := Point x: 10 y: 20. repo save: point. repo remove: point. ]. "In Pharo3.0 inspect objects and timeStamps" (repo cache instVarNamed: #objects) size -> (repo cache instVarNamed: #timeStamps) size. "Later versions inspect objects and versions" "(repo cache instVarNamed: #objects) size." (repo cache instVarNamed: #versions) size." The entries in timeStamps/versions will not go away even if one calls: repo cache performCompact The two issues I see are: 1.) VOMongoCache>>#removeValue: is leaving the timeStamp/versions alone and nobody is removing the timestamp entry and compaction will only remove keys from timeStamps/versions that were inside the objects. 2.) removeValue should most likely use self mutex criticial to guard itself. kind regards holger

Dec. 4, 2015

Re: [Pharo-dev] Java Future

by EuanM

Hi Steph, As a newcomer, here is my experience with my first bug-fix: I wrote the fix in about 5 minutes. It then took several weeks to get the big-fix accepted because of issues with the repository and, separately, with bitrot in the list of maintainers. On 30 November 2015 at 16:52, stepharo <stepharo(a)free.fr> wrote: > True help closing bug > Build a great library > Buidl a cool software > > Stef > > Le 30/11/15 04:44, EuanM a Ã©crit : > >> 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." >>> >>> >> > >

Dec. 4, 2015

Community Building [was: please name your thread]

by EuanM

Tudor, You say that we are talking about different mails. I hope so. "We need to focus on building a great platform." "acting is the only thing that will push us further.". I agree that action is what achieves things. To make sure the correct actions are taken, in a productive and efficient way, it can be valuable to take stock and think, periodically. It is important to carry out a variety of actions, not solely coding. Too narrow a focus on keeping a small group of people coding as fast as they can is not the fastest path to the end goal. It can easily lead to improving the platform at a slower rate than other great platforms are improving - a process of relative decay. I would like to help with community building efforts. But unless the leaders of the community also help and prioritise such efforts, they are unlikely to make any difference. There is no point gaining the interest of new people unless we have mechanisms in place to make them welcome, and put them on the path to becoming valuable contributors to the community. Small communities with low levels of resource must, to succeed, do things more efficiently than large groups with lots of funding. Currently, we lack: 1) debugged beginner's training materials. 2) community processes for getting the interest of new people 3) community processes for onboarding interested new people with the lowest loss rate 4) community processes for providing positive feedback and encouragement to people taking these actions. 5) community processes for stopping bit-rot in mature libraries and facilities - including key facilities like SqueakSource, Smalltalkhub and SqueakSource3 6) community processes to help focus resources on merging libraries into a single best-of-breed best-of-breed mature libraries. We often have two competing incomplete libraries for any given problem space, e.g. Spec/Bloc, MuTalk / SMutant 7) community processes to document the community processes 8) documented processes for bringing newcomers up to speed with "the way things are done round here" We need to take these issues seriously - they affect how fast things get done around here much more than this amount of time away from decoding Pharo-core does Closing down all discussions where these issues surface does not communicate "We welcome any action that anyone would want to undertake in this direction". Quite the reverse. We need to do more than just Smalltalk the Smalltalk - we need to walk the walk. Cheers, Euan Here is the thread I am keeping alive: On 30 November 2015 at 23:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > In any case, please name you thread appropriately. And, we should remember that acting is the only thing that will push us further. >> On Dec 1, 2015, at 12:18 AM, EuanM <euanmee(a)gmail.com> wrote: >> Welcoming is, as welcoming does. >> On 30 November 2015 at 11:20, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Increasing the community is certainly important, and we welcome any action that anyone would want to undertake in this direction. >>>> 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 Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >>>>>> We *should* wish to take advantage of [the rumoured Java] 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? [Full thread at foot of mail] ==================== On 30 November 2015 at 23:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I think we are not talking about the same email. > > In any case, please name you thread appropriately. And, we should remember that acting is the only thing that will push us further. > > Cheers, > Tudor > > >> On Dec 1, 2015, at 12:18 AM, EuanM <euanmee(a)gmail.com> wrote: >> >> Tudor, the email that you replied to, saying the discussion should be >> closed down, was specifically about the impacts on our community and >> how to leverage them. >> >> Welcoming is, as welcoming does. >> >> On 30 November 2015 at 11:20, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> 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. >>>>>>

Dec. 4, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Chris Cunningham

On Thu, Dec 3, 2015 at 4:51 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham > <cunningham.cb(a)gmail.com> wrote: > > <uncontrolled snipping> > > > > On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> > >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + > >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not > >> cause any error in this case. > >> > >> > >> cheers -ben > > > > > > but points aren't commutative: > > > > 2@2 + 1 " = 3@3" > > 1 + 2@2 " = 3@2" > > > > Of course, 0 wouldn't be an issue, unless you wanted to access x or y! > > > > -cbc > > whoops? > 1 + (2@2) = 3@3 > > cheers -ben > > Yeah. Forgot the parenthesis. 1 + 2@2 is the same as (1 + 2) @ 2. My eye sees the closeness of 2@2 as a point - not as a binary message (which it obviously is). So, never mind. -cbc

Dec. 4, 2015