- Pharo-dev - lists.pharo.org

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

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

by Thierry Goubier

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

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

by EuanM

Is there anything stopping us adding one more dictionary to each Monticello commit? A key of commit ids and values of author name? 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

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

by EuanM

> On 23 November 2015 at 07:24, Stephan Eggermont <stephan(a)stack.nl> wrote: > Why the link to StackOverflow? It is not our data, our community or the possibility to influence the answers. Please delete it. > I'll continue answering questions there, we should not point people there. 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. Good facilities which we do not need to write or maintain ourselves means that we can focus our effort on other things. There is no reason for us to re-invent a question-and-answer facility, or do the work of keeping it as searchable as a curated site is. 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. 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. 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. Do we use Slack, or have we built our own? We don't own the Slack data. Slack is not our community. 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? 4) Why Stack Overflow? There was a famous bank robber in the USA who was on the FBIâs list of Ten Most Wanted Fugitives. He was asked by a reporter "Why do you rob banks?" His answer was "Because that's where the money is." 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. At Stack Overflow, we have the opportunity to access the hearts and minds of a *very* large group of developers. We are a very small community, chronically short of developers, documenters, testers, and many other roles. Stack Overflow is a good way to help us encourage people to express interest, and possibly even join us. Stronger, wider, deeper awareness of the benefits of our platform can only help interest in using it. Pharo is not intended as an academic pursuit. It is intended to help make a difference: to the professional lives of developers; to organisations; and to individuals who need a good way of being introduced to OO fundamentals. We make the best difference by making a difference to a large number of people and organisations. We make the best difference if a lot of people help us accelerate the speed of progress and help us complete and maintain and document our feature sets. Cheers, Euan

Nov. 30, 2015