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

Re: [Pharo-dev] Code critic very bugged ?

by Dimitris Chloupis

And I found the one responsible is either, with my project Ephestos which the only funky thing it does is to override an objects MNU or SmaCC which Ephestos also installs and depends one and it has given me several crashes so far. And this happens if I try to install Ephestos via command line , I use a makefile, if I install Ephestos via the GUI Package Browser, no MNUs no problemo. I am using from command line pharo Ephestos/Ephestos.image get Ephestos So problem solved, dont load Ephestos from command line , though I have not tested other ways of loading from command line maybe get is to blame here or something else. No clue. But at least i found a solution and I apologize for blaming Code Critics and QualityAssistant. On Sun, Nov 8, 2015 at 8:31 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > nope still shortcuts bugged in monticello and I am also getting white box > of death, this is fun ! > > I am getting MNUs pretty much everywhere now. Will try getting a new image > . > > Looks like this problems goes deeper than QA. No idea what it may be. > > > > > > > > On Sun, Nov 8, 2015 at 7:15 PM Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> What do you do to end up with that? It doesnât look like code critics, >> itâs more on Rubric side. And if disabling QAPlugin helps to avoid that, >> then most likely QA hijacks Rubric functionality somehow that I canât >> imagineâ¦ >> >> Cheers, >> Uko >> >> >> >> >> On 08 Nov 2015, at 12:57, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >> ah I forgot about that one, yes it does here it is >> >> http://pastebin.com/uW4AMphu >> >> On Sun, Nov 8, 2015 at 1:37 PM Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> 2015-11-08 12:27 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >>> >>>> Hey guys I try to use shortcuts and arrow keys with nautilus and I get >>>> this every time >>>> >>>> MNU : receiver of doSemanticsAnalysis: is nil >>>> >>>> in ASTCache at: aCompiledMethod >>>> >>>> I would paste the full stack but it keeps throwing me MNUs when I try >>>> to do anything with the debugger. Seems like a pretty major bug , am I the >>>> only one experiencing this ? >>>> >>> >>> does the pharodebug.log contain the stack trace? >>> >>> >>> >>>> >>>> I am on macos Yosemite using latest pharo 5 image and stable vm with >>>> >>>> wget -O- get.pharo.org/50+vm | bash >>>> >>>> >>>> >>

Nov. 8, 2015

Re: [Pharo-dev] Changing class template

by stepharo

So this is good your super students will not have to worry and my super stupid will be happy. Le 8/11/15 20:14, Thierry Goubier a Ã©crit : > Stef, > > I don't understand. I have never set a category in a class creation > template for the last three years. > > When I teach using Pharo, I allways tell students to create a package, > select the package in the browser and add a class there. > > Changing #category: for #package: (which is what the fix will be, I > bet) is useless. > > Thierry > > Le 08/11/2015 19:55, stepharo a Ã©crit : >> https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation >> >> Stef >> >> Hi guys >> >> I think that not enough of us are teaching... we are so used to jump >> around >> "DETAILS" that we do not have a clue how newcomers see our system. >> >> For example I hate that I have to explain that we should enter a package >> name as argument of a category???? >> >> Object subclass: #NameOfSubclass >> instanceVariableNames: ââ >> classVariableNames: ââ >> category: âPackageNameâ >> >> >> I will change the template because I do not want to have to explain that >> and that our Mooc refers to such crap. And you will have the right to >> complain but in that case >> I will tell you: "give a lecture and come back to" >> >> We are trapped in our way of thinking and we are trapped in the glitches >> of our system >> >> We should not accept glitches and we should kill them. >> >> Stef > > > >

Nov. 8, 2015

Re: [Pharo-dev] Changing class template

by Ferlicot D. Cyril

Le 08/11/2015 20:14, Thierry Goubier a Ã©crit : > Stef, > > I don't understand. I have never set a category in a class creation > template for the last three years. > > When I teach using Pharo, I allways tell students to create a package, > select the package in the browser and add a class there. > > Changing #category: for #package: (which is what the fix will be, I bet) > is useless. > > Thierry > > I understand because when I explain a little Pharo to friends who only learned Java, I like to explain the advantage to have everything as an object and every action as a message. And one of the first message we encounter is the class template. We can explain Â«We send this message to "Object" and with this message we have arguments which areâ¦Â». But when it comes to the package we have to say Â«And for the category you pass the package name and don't care about the "category" nameÂ» because this is too much to explain the tags thing to beginners. I think that what is easily visible should be very explicit, and more advances feature should be in menu or things like that to help beginners. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 8, 2015

Re: [Pharo-dev] Changing class template

by Thierry Goubier

Stef, I don't understand. I have never set a category in a class creation template for the last three years. When I teach using Pharo, I allways tell students to create a package, select the package in the browser and add a class there. Changing #category: for #package: (which is what the fix will be, I bet) is useless. Thierry Le 08/11/2015 19:55, stepharo a Ã©crit : > https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation > > Stef > > Hi guys > > I think that not enough of us are teaching... we are so used to jump around > "DETAILS" that we do not have a clue how newcomers see our system. > > For example I hate that I have to explain that we should enter a package > name as argument of a category???? > > Object subclass: #NameOfSubclass > instanceVariableNames: ââ > classVariableNames: ââ > category: âPackageNameâ > > > I will change the template because I do not want to have to explain that > and that our Mooc refers to such crap. And you will have the right to > complain but in that case > I will tell you: "give a lecture and come back to" > > We are trapped in our way of thinking and we are trapped in the glitches > of our system > > We should not accept glitches and we should kill them. > > Stef

Nov. 8, 2015

Changing class template

by stepharo

https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation Stef Hi guys I think that not enough of us are teaching... we are so used to jump around "DETAILS" that we do not have a clue how newcomers see our system. For example I hate that I have to explain that we should enter a package name as argument of a category???? Object subclass: #NameOfSubclass instanceVariableNames: ââ classVariableNames: ââ category: âPackageNameâ I will change the template because I do not want to have to explain that and that our Mooc refers to such crap. And you will have the right to complain but in that case I will tell you: "give a lecture and come back to" We are trapped in our way of thinking and we are trapped in the glitches of our system We should not accept glitches and we should kill them. Stef Class and Method Definition Class and Method Definition

Nov. 8, 2015

Cannot use command-P in inspector in the debugger

by stepharo

Hi guys I would like to know if I'm the only one to do not have anymore the command-P in inspector in the debugger. Stef

Nov. 8, 2015

Re: [Pharo-dev] Code critic very bugged ?

by Dimitris Chloupis

nope still shortcuts bugged in monticello and I am also getting white box of death, this is fun ! I am getting MNUs pretty much everywhere now. Will try getting a new image . Looks like this problems goes deeper than QA. No idea what it may be. On Sun, Nov 8, 2015 at 7:15 PM Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > What do you do to end up with that? It doesnât look like code critics, > itâs more on Rubric side. And if disabling QAPlugin helps to avoid that, > then most likely QA hijacks Rubric functionality somehow that I canât > imagineâ¦ > > Cheers, > Uko > > > > > On 08 Nov 2015, at 12:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > ah I forgot about that one, yes it does here it is > > http://pastebin.com/uW4AMphu > > On Sun, Nov 8, 2015 at 1:37 PM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> 2015-11-08 12:27 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> Hey guys I try to use shortcuts and arrow keys with nautilus and I get >>> this every time >>> >>> MNU : receiver of doSemanticsAnalysis: is nil >>> >>> in ASTCache at: aCompiledMethod >>> >>> I would paste the full stack but it keeps throwing me MNUs when I try to >>> do anything with the debugger. Seems like a pretty major bug , am I the >>> only one experiencing this ? >>> >> >> does the pharodebug.log contain the stack trace? >> >> >> >>> >>> I am on macos Yosemite using latest pharo 5 image and stable vm with >>> >>> wget -O- get.pharo.org/50+vm | bash >>> >>> >>> >

Nov. 8, 2015

Re: [Pharo-dev] Code critic very bugged ?

by Yuriy Tymchuk

What do you do to end up with that? It doesnât look like code critics, itâs more on Rubric side. And if disabling QAPlugin helps to avoid that, then most likely QA hijacks Rubric functionality somehow that I canât imagineâ¦ Cheers, Uko > On 08 Nov 2015, at 12:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > ah I forgot about that one, yes it does here it is > > http://pastebin.com/uW4AMphu <http://pastebin.com/uW4AMphu> > > On Sun, Nov 8, 2015 at 1:37 PM Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > 2015-11-08 12:27 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>>: > Hey guys I try to use shortcuts and arrow keys with nautilus and I get this every time > > MNU : receiver of doSemanticsAnalysis: is nil > > in ASTCache at: aCompiledMethod > > I would paste the full stack but it keeps throwing me MNUs when I try to do anything with the debugger. Seems like a pretty major bug , am I the only one experiencing this ? > > does the pharodebug.log contain the stack trace? > > > > I am on macos Yosemite using latest pharo 5 image and stable vm with > > wget -O- get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash > >

Nov. 8, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Thierry Goubier

Le 08/11/2015 17:41, Dale Henrichs a Ã©crit : > > > On 11/7/15 10:00 AM, Thierry Goubier wrote: >> Oh yes, >> >> I can announce that from now on, the development version of >> GitFileTree for Pharo 5 handles FileTree repositories without most of >> the metadata (precisely version and methodProperties). >> >> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN, >> all...) by cutting the noise on diffs and conflicts on merge and >> cherry picking. >> >> Note: it only apply to brand new repositories; nothing is changed for >> pre-existing ones. >> >> Note2: reading those Metadata-less repositories with FileTree does >> give you packages without metadata: no version history, no author, no >> author nor timestamp on methods. >> >> Note3: it is possible to hack a repo from metadata to non-metadata >> mode, but I won't explain it. >> >> Enjoy and tell me how it works for you. I'm especially interested by >> heavy branchers/mergers reports :) >> >> Thierry >> > Thierry, > > You want to double check that Metacello works correctly with these > metadata-less packages ... if you are continuing to increment the > "package version" there shouldn't be a problem, but when I did a similar > experiment a year or so ago, I found that I had to teach Metacello to > ignore the "package version" and load the package anyway ... the normal > procedure for Monticello packages and Metacello is not load a package if > the "package version" is less than or equal to the package already > loaded .... I did make an extension to Metacello to make this work .... > I can hunt it up if needed and make it part of the standard release (I > may have kept it as part of tODE) ... Hi Dale, GitFileTree without metadata on disk does not mean no metadata for Monticello/Metacello to work with; as long as you reach the git log info, then it will work exactly as usual (incrementing version numbers, etc...), with the usual caveats (i.e., if you limit depth when cloning with git, version numbers do change). However, when accessing via FileTree (for example github:// urls), then, yes, version numbers become 1. It will only matter when updating an already loaded project via a github:// or bitbucket:// url. And there, simply allowing Metacello to load if repository version is >= to existing version should take care of it. I have an idea of possible solutions. We'll see how it goes and solve that when we'll have a serious push around git ;) Thierry

Nov. 8, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

On 11/7/15 10:00 AM, Thierry Goubier wrote: > Oh yes, > > I can announce that from now on, the development version of > GitFileTree for Pharo 5 handles FileTree repositories without most of > the metadata (precisely version and methodProperties). > > This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN, > all...) by cutting the noise on diffs and conflicts on merge and > cherry picking. > > Note: it only apply to brand new repositories; nothing is changed for > pre-existing ones. > > Note2: reading those Metadata-less repositories with FileTree does > give you packages without metadata: no version history, no author, no > author nor timestamp on methods. > > Note3: it is possible to hack a repo from metadata to non-metadata > mode, but I won't explain it. > > Enjoy and tell me how it works for you. I'm especially interested by > heavy branchers/mergers reports :) > > Thierry > Thierry, You want to double check that Metacello works correctly with these metadata-less packages ... if you are continuing to increment the "package version" there shouldn't be a problem, but when I did a similar experiment a year or so ago, I found that I had to teach Metacello to ignore the "package version" and load the package anyway ... the normal procedure for Monticello packages and Metacello is not load a package if the "package version" is less than or equal to the package already loaded .... I did make an extension to Metacello to make this work .... I can hunt it up if needed and make it part of the standard release (I may have kept it as part of tODE) ... Dale

Nov. 8, 2015