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

Unable to open context-menu in debugger inspector (Pharo 5)

by Esteban A. Maringolo

When I try to open the context menu in a workspace (not Playground) or in the code pane of an inspector I get the following: When I debug I get the following exception: "MessageNotUnderstood: MorphicTextAdapter>>acceptAllowed" The image is Pharo-5.0-50473 Regards! Esteban A. Maringolo ps: Stack trace MorphicTextAdapter(Object)>>doesNotUnderstand: #acceptAllowed RubPlainTextMode class>>menuOn: [ prg methodClass theNonMetaClass perform: prg selector with: menu ] in [ :prg | self currentRoot: self while: [ prg methodClass theNonMetaClass perform: prg selector with: menu ] ] in PragmaMenuBuilder>>collectRegistrations in Block: [ prg methodClass theNonMetaClass perform: prg sel...etc... [ aBlock value ] in PragmaMenuBuilder>>currentRoot:while: in Block: [ aBlock value ] BlockClosure>>ensure:

Nov. 30, 2015

Re: [Pharo-dev] Nautilus class definition pane and browseAllAccessesTo

by stepharo

If I remember the interaction model captures the following: Rubric a model for the text but this is not the one of the interaction. For example if you want to be able to cancel your edit you should edit the rubric model but the interaction model. Then the interaction model is turned into a rubric model on okToSave Stef Le 30/11/15 00:28, Nicolai Hess a Ã©crit : > > > 2015-11-30 0:07 GMT+01:00 Henrik Nergaard <henrin10(a)student.uia.no > <mailto:henrin10@student.uia.no>>: > > For the Rubric keybinding; changing the calls using âself modelâ > in RubSmalltalkEditor>>#modelCurrentSelectedClass to call âself > model interactionModelâ instead should make the keybinding work > again (at least changing the one to #selectedBehaviour). > > > Yes! But I must admit that I don't understand the purpose of the > interactionModel, why does the text model has an interaction model ? > Do all text model provide it ? > > Best regards, > > Henrik > > *From:*Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <mailto:pharo-dev-bounces@lists.pharo.org>] *On Behalf Of *Nicolai > Hess > *Sent:* Sunday, November 29, 2015 10:32 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org > <mailto:pharo-dev@lists.pharo.org>> > *Subject:* [Pharo-dev] Nautilus class definition pane and > browseAllAccessesTo > > In Nautilus class definition pane, if it shows a class definition like > > Object subclass: #RBNamespace > instanceVariableNames: 'changes environment newClasses > removedClasses changedClasses rootClasses implementorsCache > sendersCache' > classVariableNames: '' > package: 'Refactoring-Core-Model' > > you can select an inst var and > > use cmd+shift+n to browse all accesses to this var. > > I broke this behavior. ( But I find it useful and a I want it back). > > The problem, Rubric needs to know the current selected class (it > calls classOrMetaclass on the > > *interaction model* (Nautilus) to find the class it searches for > this inst var. > > But the same method #classOrMetaclass is called by NEC, and if NEC > finds a class > > it trys to parse the current text as a method definition, but this > panes contains a > > class definition, not a method definition, and this yields to the > strange completions > > (case 16712) this is what I tried to fix when I broke this > browseAllAccessesTo behavior. > > Any Idea how we can get both ? > > - Rubric to find the correct class for browsing inst var access > > - NEC to find *no class* so it does not try to complete the inst > var names. > > I don't know how to solve this, I don't understand how rubric > delegates this > > calls (it should be possible to call #selectedBehavior or > #selectedClass but it > > uses some delegates > > rub editing -> rub editor -> rub scrolled text model -> > interaction model -> nautilus ui > >

Nov. 30, 2015

Re: [Pharo-dev] Java Future

by stepharo

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

Nov. 30, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Tudor Girba

Hi, I created an issue for this: https://pharo.fogbugz.com/f/cases/17170/Context-missing-primitives Cheers, Doru > On Nov 19, 2015, at 3:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Please tell me more specifically what needs to be done. Could you give me a concrete example of an object that cannot be inspected? > > Cheers, > Tudor > > >> On Nov 18, 2015, at 6:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> 2015-11-18 13:29 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>> >>> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>> Iâd like to discuss also the possibility to add those low level operations >>>> on mirrors objects, that could be packaged separately from the kernel of the >>>> language. Adding them on a first step is easy, then making all tools use >>>> them is the hard/timeconsuming part, yes. >>> >>> >>> All the needed operations already exist. You can put them on your mirror >>> objects without any problem. >> >> >> Who takes the decision to put it either in EyeInspector or GtInspector? >> >> Regards! >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Nov. 30, 2015

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

by Stephan Eggermont

On 30-11-15 11:06, Nicolai Hess wrote: > no issue validation since last weekend. We now get timeout within a few minutes Stephan

Nov. 30, 2015

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

by Yuriy Tymchuk

You can start a âFuture of Pharoâ discussion on a Java mailing list :) Cheers. Uko > On 30 Nov 2015, at 12:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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] red banner and links with safari?

by Ben Coman

I do agree there is some lost opportunity since fast/good responses on SO provides a benchmark of the community for some people. However the overarching answer is that parties outside our community (senior SO members) tune in to police "our" responses to questions posed to us and close discussions as "not constructive" or "not suited to the site". Complaints that our community was quite happy to answer such questions posed to us went nowhere. cheers -ben On Mon, Nov 30, 2015 at 12:16 PM, EuanM <euanmee(a)gmail.com> wrote: >> 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

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

by Ben Coman

There is git-notes... http://git-scm.com/docs/git-notes but it seems a little complicated to manage... "Git notes are annotations for existing commits. They donât change the history, so you are free to add notes to any existing commits. Your notes are stored only in your repo, but itâs possible to share notes. " http://mislav.net/2010/07/git-tips/ http://lists-archives.com/git/714256-git-notes-usage.html cheers -ben On Mon, Nov 30, 2015 at 2:41 PM, EuanM <euanmee(a)gmail.com> wrote: > 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] Nice text about the role of (user interface) design

by Thierry Goubier

Cool, Don Norman. The man of "The Design of Everyday Things", and the Affordance concept... Stephan, you have very good references :) Thierry 2015-11-30 12:48 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > 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

Help needed: old issues issue tracker entries

by marcus.denker＠inria.fr

Hi, The issue tracker has 658 open issues. This number is more or less constant. We are fixing and integrating *a lot*, alone the last 7 days we managed to close 89 issue tracker entries. But the older entries see not much work. Of course one reason is that everything fixable gets fixed and only hard cases remainâ¦ but cases can be âdifficultâ for many reasons. I would be nice if everyone could help and have a look at older issues: -> Still relevant? -> Maybe already fixed? -> Is the description good? -> What is the next action that needs to be done? And keep in mind that the issue tracker is not a TODO list. If you see something odd and put and issue âoh, this looks oddâ but there is no action for a year, does it really make sense to keep that issue open? Every open issue takes energy away from the others. So please check if issues make sense of this kind: -> âIt would be nice ifâ but not even important enough for the submitter to do -> TODO issues that are huge projects in themselves -> â¦. It would be nice if *you* would check the issue that you have been involved with the last months and see what is needed to solve them. Marcus

Nov. 30, 2015