- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Analyzing Tweets

by stepharo

Le 28/11/15 08:38, stepharo a Ã©crit : > > > Le 26/11/15 19:44, Alexandre Bergel a Ã©crit : >> Hi! >> >> Some students from Arizona State University are analyzing some >> tweets. This is pretty cool. Here are some short video and url full >> of pictures: >> >> https://sites.google.com/a/asu.edu/project-geeko/ >> https://drive.google.com/file/d/0BxQoWoSofKvaTkN5bk9hN0NyQ28/view >> https://www.youtube.com/watch?v=cnuc_crnWB0&feature=youtu.be > > it is the correct youtube link because I get a different video? Yes the thumbnail was strange >> >> Impressive! >> >> Cheers, >> Alexandre > > >

Nov. 28, 2015

Re: [Pharo-dev] Analyzing Tweets

by stepharo

Le 26/11/15 19:44, Alexandre Bergel a Ã©crit : > Hi! > > Some students from Arizona State University are analyzing some tweets. This is pretty cool. Here are some short video and url full of pictures: > > https://sites.google.com/a/asu.edu/project-geeko/ > https://drive.google.com/file/d/0BxQoWoSofKvaTkN5bk9hN0NyQ28/view > https://www.youtube.com/watch?v=cnuc_crnWB0&feature=youtu.be it is the correct youtube link because I get a different video? > > Impressive! > > Cheers, > Alexandre

Nov. 28, 2015

Re: [Pharo-dev] Analyzing Tweets

by stepharo

Le 26/11/15 19:44, Alexandre Bergel a Ã©crit : > Hi! > > Some students from Arizona State University are analyzing some tweets. with Pharo > This is pretty cool. Here are some short video and url full of pictures: > > https://sites.google.com/a/asu.edu/project-geeko/ > https://drive.google.com/file/d/0BxQoWoSofKvaTkN5bk9hN0NyQ28/view > https://www.youtube.com/watch?v=cnuc_crnWB0&feature=youtu.be > > Impressive! > > Cheers, > Alexandre

Nov. 28, 2015

Re: [Pharo-dev] Improving API of Date, Month....

by Francisco Ortiz PeÃ±aloza

I agree with Esteban on Chalten. Chalten currently loads on Pharo 4 and 5 without any issue. It has a lots of tests cases that help a lot to learn about it. On Thu, Nov 26, 2015 at 8:55 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I donât know chronos, but Chalten (the Aconcagua date API) is quite nice > (overuse of globals, IMO, but you gain a lot of expressivity). > > Esteban > > > On 24 Nov 2015, at 18:34, stepharo <stepharo(a)free.fr> wrote: > > > > Hi guys > > > > I made the mistake to think that it was a good move to improve and make > the core more full (and complex in the past). > > Now what I would love is the following. > > > > - keep and reduce if necessary the core date classes (only used > internally by the system) > > - have nice packages that we can load to represent time / calendar > > -- chronos > > -- aconcagua > > -- or a new one > > > > That do it the right way: with locale and so on. > > Why? because it can be complex and verbose and we want to have a small > core (for many different reasons). > > About the durationFormatter I think that we should definitively have > more strategies to represent dates and other > > within a nice date/calendar package. > > > > I would love that someone propose something to get the nice extensible > Calendar/Date package > > > > Stef > > > > Le 24/11/15 16:25, Esteban A. Maringolo a Ã©crit : > >> 2015-11-24 12:14 GMT-03:00 Skip Lentz <skip.lentz(a)inria.fr>: > >>> Hi, > >>> > >>> I also had an idea for a method which returns the most significant > unit of a Duration. > >>> > >>> For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 > seconds, etc., and > >>> it would return you "432 days" (or just â1 yearâ). I encountered this > when wanting to create > >>> a time indication on e.g. a commit or a comment. Itâs much more > readable and user-friendly > >>> than a timestamp. > >>> > >>> Would this be a nice addition to the Duration API? > >> It would be nice to have. But why not something like a > >> DurationFormatter? that in turn collaborates with the Locale to ge the > >> words for "Year, Month, Week" in the current language. > >> > >> Regards! > >> > >> > > > > > > >

Nov. 27, 2015

Re: [Pharo-dev] Java Future

by Tudor Girba

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

Nov. 27, 2015

Re: [Pharo-dev] Java Future

by EuanM

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

Nov. 27, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 27, 2015

[pharo-project/pharo-core] 03478d: 50476

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 03478dae50cdd47c2e344f679f2e6c9a87f13e83 https://github.com/pharo-project/pharo-core/commit/03478dae50cdd47c2e344f67… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-27 (Fri, 27 Nov 2015) Changed paths: M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositories.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositoryGroup.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositoryList.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositorySelection.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/README.md A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/definition.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/running/setUp.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testDefault.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testRepositories.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testRepositoriesIncludeCache.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testRepositoryList.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/error handling/unusedVariable_.st R OpalCompiler-Core.package/OCUnusedVariableWarning.class/README.md R OpalCompiler-Core.package/OCUnusedVariableWarning.class/definition.st R OpalCompiler-Core.package/OCUnusedVariableWarning.class/instance/accessing/node_.st R OpalCompiler-Core.package/OCUnusedVariableWarning.class/instance/correcting/defaultAction.st R OpalCompiler-Tests.package/OCCompilerExceptionsTest.class/instance/tests/testUnusedVariable.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/README.md A Reflectivity-Tools.package/SemanticWarningIconStyler.class/definition.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/defaults/highlightColor.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/defaults/iconFor_.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/defaults/iconLabel_.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/testing/shouldStyleNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50475.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50476.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50475.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50476.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Debugger.package/SpecDebugger.class/definition.st M Spec-Debugger.package/SpecDebugger.class/instance/initialization/initialize.st R Spec-Debugger.package/SpecDebugger.class/instance/private/onWidgetBuilt.st Log Message: ----------- 50476 17151 MCWorkingCopyBrowser needs some love https://pharo.fogbugz.com/f/cases/17151 17154 Add a highlight to tempvar declarations when they are unused https://pharo.fogbugz.com/f/cases/17154 15543 Add a menu to add the Meta catalog of Pharo to MC https://pharo.fogbugz.com/f/cases/15543 17091 SpecDebugger has unused vars https://pharo.fogbugz.com/f/cases/17091 http://files.pharo.org/image/50/50476.zip

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Dimitris Chloupis

yes as always you are correct I lost the names of all my temporary variables but I got that fixed by reimporting the filetree repository. Thank you for your efforts they never go unnoticed. By the way this is a fresh image that does this, I use a startup script to load all my libraries. Maybe one of those libs does something funky to the changes file. Epicea looks interesting. The one thing that makes me wonder is how needed the image file format really is. I get it that is there to store the complete live enviroment but even in that case it can still be broken to individual files each with a specific role, some binary and some text. Afterall there is no reason why state cannot be stored even in text files. In any case I know you guys have many good ideas to improve the situation and I am sure with time you will. On Fri, Nov 27, 2015 at 7:37 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 27 Nov 2015, at 13:32, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Marcus you are awesome thank, so all I had to do was erase my > Ephestos.changes file and now I can browse addMiscExtraTo: and I have no > MNUs or red boxes of doom. > > > > There was something fishy about my changes file, I found addMiscExtraTo: > in PharoV4.sources and in Ephestos.changes, the issue is that I never > touched that method , so why should it be in changes file ? I thought > changes are for the things you change in the image. > > > > But no complains , it looks like now the problem is gone. > > > > The .changes does not only have the changes that you did, but in addition > all changes that we did to Pharo since the release of Pharo4â¦ > > The whole mechanism is not very goodâ¦ we really should replace it. The > good news is that we are working on the first step > already: Epicea will be used for recording changes, so after that we re > free to simplify source storage as it will now overlap anymore > with change history recording. > > Be careful with an image where you delete the .changes: all methods that > point to that file will be decompiledâ¦ losing comments and much more. > > The best thing is to re-create an image from the release (loading your > code). > > Marcus >

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Marcus Denker

> On 27 Nov 2015, at 13:32, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom. > > There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image. > > But no complains , it looks like now the problem is gone. > The .changes does not only have the changes that you did, but in addition all changes that we did to Pharo since the release of Pharo4â¦ The whole mechanism is not very goodâ¦ we really should replace it. The good news is that we are working on the first step already: Epicea will be used for recording changes, so after that we re free to simplify source storage as it will now overlap anymore with change history recording. Be careful with an image where you delete the .changes: all methods that point to that file will be decompiledâ¦ losing comments and much more. The best thing is to re-create an image from the release (loading your code). Marcus

Nov. 27, 2015