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

Re: [Pharo-dev] Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil

by Marcus Denker

I will put it on the TODOâ¦. sadly I am a bit busy and canât postpone the other things now to work on this. > On 20 Nov 2015, at 18:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Any idea how to solve this: > > 16961 <https://pharo.fogbugz.com/f/cases/16961/Unable-to-accept-changes-in-SyntaxE…> Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil > and > 16723 <https://pharo.fogbugz.com/f/cases/16723/File-in-a-file-with-an-error-does-n…> File in a file with an error does not set the doitFlag well > > If you file in some code that with syntactic errors, you can not fix the > code from within SyntaxErrorDebugger because > 1. the doitflag is nil, and If we would change this, init it with true... > 2. ... the category is nil > > From where it is used and comments like: > > notify: message at: location in: code > self flag: #hack. > "Should use the new OPalWarnings directly instead of recreating a SyntaxErrorNotification" > SyntaxErrorNotification > inClass: STCommandLineHandler > category: nil > withCode: code > doitFlag: nil > errorMessage: message > location: location. > > it looks like the usage for SyntaxErrorNotification should be cleaned reworked, > any ideas what to do? > I can not find a Opal OCSytaxEror or something like this. And I don't understand > the workflow of raising and catching and reraising SyntaxErrorNotifications. > > > >

Nov. 24, 2015

Re: [Pharo-dev] News about FastTable

by Ferlicot D. Cyril

Le 18/11/2015 10:53, Ferlicot D. Cyril a Ã©crit : > Hi everyone! > > I just wanted to say that I added a first version of Tree in FastTable > and I corrected some bugs. > > If someone want to try it and give some feedback you can see some > examples on the latest Pharo 5 in FTExamples class. > > With Usman we also worked on the glamour version of FastTable begun by > Esteban. > You can see some examples of FastList, FastTable, FastOutlineList and > FastTree in the GLMExamplesBrowser after executing this: > > (ConfigurationOfFastTable project version: #stable) load: #glamour > > Every feedback is welcome :) > Hi, I took into account your feedback. I corrected the broken examples. I copied the Glamour package into glamour repository. I did not produced a new configuration yet. Now the FastTree selection is updated when we collapse/extend an item. The selection of collapsed item is not saved because with the current implementation of FastTable that would be really complex. I think that if someone want to have a widget with this feature that should be a subclass of FTTreeDataSource and not a basic feature. And I did some small changes. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 24, 2015

Re: [Pharo-dev] problem using curl and wget in zero-conf

by Ben Coman

On Tue, Nov 24, 2015 at 7:25 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > I've been using zero-conf scripts to download the pharo vm for a while and > occasionally the download fails to install the vm in the pharo-vm directory > .... silently ..... with no clue as to what happened. even worse the exit > status is zero so the failure isn't noticed until much later on in my > install when an attempt is made to actually use the vm So to fail early after the download we should... if [ ! -f "$VM_DIR/vm.zip" ] ; then echo "BOOM!" exit 1; fi (?) cheers -ben > .... I do know that when I see these failures the pharo-vm [directory] > does get created but is empty ... > > I got another failure today and figured that I would dig into this on my end > to see if I could understand what might be going on .... > > The section of the zero-conf script that is suspect is the following: > > mkdir $VM_DIR > $DOWNLOAD_TO$VM_DIR/vm.zip $VM_URL > > > After the $VM_DIR is created (which I know happens), the $DOWNLOAD_TO script > is run. Recently, I learned that a side effect of using the --silent option > for curl is that error messages are also suppressed and I see that for curl, > the `--silent` option is being used: > > if [[ `which curl 2> /dev/null` ]]; then > DOWNLOAD="curl --silent --location --compressed "; > DOWNLOAD_TO="$DOWNLOAD --output "; > elif [[ `which wget 2> /dev/null` ]]; then > DOWNLOAD_TO="wget --quiet --output-document="; > DOWNLOAD="$DOWNLOAD_TO-"; > else > echo "Please install curl or wget on your machine"; > exit 1 > fi > > > For curl if you want to turn off the progress meter (a good thing) and > continue to report errors, you need to use --show-error in conjunction with > --silent (as described in the man page) > > I think the same thing applies to wget, --quiet turns off error messages and > progress .... you probably should be using --no-verbose to continue to get > error messages ... > > Dale > >

Nov. 24, 2015

Re: [Pharo-dev] ReÂ : Re: Metacello load script won't update the configuration

by Christophe Demarey

Le 23 nov. 2015 Ã 20:32, Marcus Denker a Ã©crit : > >> On 23 Nov 2015, at 16:25, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> I did the configuration 2 months ago but was not integrated because of some critics rules failing. And some of them are not valid for a project supporting many smalltalk and many versions. >> I synchronized all the code and tests were green. >> The code is not worst as the current metacello version so I do not see why it is not integrated. >> > > because with >650 issues I do never look through all of them because an issue âWork neededâ might be ready for integration. > I *only* look at issues that are âfix review neededâ or âfix reviewed by the monkeyâ. That is easily understandable. What I meant is that StÃ©phane tried to integrate it (I told StÃ©phane that it was ready) but the integration failed and I did not get the reason back. I will try to resync (again) and provide critics feedback to Dale.

Nov. 24, 2015

Re: [Pharo-dev] Rules

by Yuriy Tymchuk

Essentially there should be 3 things: 1) clear name like: 'super' should receiver the same message (or similar). 2) good rationale explaining that you have to send the message to self and then either override it or let it run from supper, as this allows better flexibility. 3) make an automate fixing (as it is trivial). It should be doable by rewrite rules I suppose, but what annoys me is that when you use them, you donât have the matched string, nor the interval, so you cannot highlight itâ¦ Anyway, it is on my todolist. Cheers. Uko > On 24 Nov 2015, at 09:32, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote: > > > > On 23/11/2015 22:14, stepharo wrote: >> >> >> Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : >>> Hi. >>> >>> The rule is correct. Sending a different message to super may be confusing. In this case you are in âprintOn:â method and you are sending âprintOn:nextPutAll:â to super. The idea is that you have to send âprintOn:nextPutAll:â to self and then either it will invoke the super one, you there will be an overridden method in your current class. >> >> exactly but do you expect a newbie to understand anything with the current explanation? >> I do not. >> >> " >> >> Rewrite super messages to self messages when both refer to same method" > What about : > "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." > ? > > or: > > "should not send a different message to super (send different message to self and then call super from it)" > ? > > > > nicolas >> >> Sucks >> >>> >>> Secondly, there is an issue with âsends unkown selectorâ. Iâve also noticed it recently. I think that it happens because the rule has a special cace, and I messed up something with refresh. This is the next thing on my TODO list. >>> >>> Cheers. >>> Uko >>> >>> >>>> On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> >>>>> On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> With the following (broken) definition >>>>> >>>>> >>>>> : aStream >>>>> super printOn: aStream >>>>> aStream nextPutAll: '(', faces printString , ')' >>>>> >>>>> I got this strange rule: >>>>> >>>>> Rewrite super messages to self messages when both refer to same method >>>>> >>>>> I do not get it and it looks really suspicious to me. >>>>> Any suggestions? >>>> The rule is meant to catch the case when when âsuperâ can be âselfâ as there is no #printOn: >>>> defined in the class. >>>> >>>> But here it looks like it is wrong: it would be an infinite loop. >>>> >>>> I think it could be related to this other bug: I have seen that the rules are not correctly updated >>>> when you add methods. (I wanted to add an issue for that but did not yet). E.g. I often get >>>> a âsends unkown selectorâ for self sends and then I check â> method is there, I just added it! >>>> >>>> So here this means that you added a new printOn:, the rules do not update, and it thinks >>>> that there is no printOn:. >>>> >>>> So the real bug is that added methods need to be taken into account by QA. >>>> >>>> Marcus >>> >>> >> >> > > -- > Nicolas Anquetil > RMod team -- Inria Lille

Nov. 24, 2015

Re: [Pharo-dev] Rules

by Nicolas Anquetil

On 23/11/2015 22:14, stepharo wrote: > > > Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : >> Hi. >> >> The rule is correct. Sending a different message to super may be >> confusing. In this case you are in âprintOn:â method and you are >> sending âprintOn:nextPutAll:â to super. The idea is that you have to >> send âprintOn:nextPutAll:â to self and then either it will invoke the >> super one, you there will be an overridden method in your current class. > > exactly but do you expect a newbie to understand anything with the > current explanation? > I do not. > > " > > Rewrite super messages to self messages when both refer to same method" What about : "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." ? or: "should not send a different message to super (send different message to self and then call super from it)" ? nicolas > > Sucks > >> >> Secondly, there is an issue with âsends unkown selectorâ. Iâve also >> noticed it recently. I think that it happens because the rule has a >> special cace, and I messed up something with refresh. This is the >> next thing on my TODO list. >> >> Cheers. >> Uko >> >> >>> On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>>> On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> With the following (broken) definition >>>> >>>> >>>> : aStream >>>> super printOn: aStream >>>> aStream nextPutAll: '(', faces printString , ')' >>>> >>>> I got this strange rule: >>>> >>>> Rewrite super messages to self messages when both refer to same >>>> method >>>> >>>> I do not get it and it looks really suspicious to me. >>>> Any suggestions? >>> The rule is meant to catch the case when when âsuperâ can be âselfâ >>> as there is no #printOn: >>> defined in the class. >>> >>> But here it looks like it is wrong: it would be an infinite loop. >>> >>> I think it could be related to this other bug: I have seen that the >>> rules are not correctly updated >>> when you add methods. (I wanted to add an issue for that but did not >>> yet). E.g. I often get >>> a âsends unkown selectorâ for self sends and then I check â> method >>> is there, I just added it! >>> >>> So here this means that you added a new printOn:, the rules do not >>> update, and it thinks >>> that there is no printOn:. >>> >>> So the real bug is that added methods need to be taken into account >>> by QA. >>> >>> Marcus >> >> > > -- Nicolas Anquetil RMod team -- Inria Lille

Nov. 24, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Dimitris Chloupis

I suggest all interested parties to > > - review the code of skip > absolutely I already have begun to do it > - let him some time to improve > no rush at all from my side, he has as much time as he wants > - help if you want > I offer to design a custom GUI for it ;) but first I will let you get the functionality right and I can learn from the code as well in the meantime because I am not familiar with the REST API at all :) > The goal of skip internship with us is to build a better code review > system for Pharo. > And we decided to use existing infrastructure instead of building our own > seaside-based yet another server to maintain. > > good choice, afterall pharo already greatly benefits from taking advantage of existing technologies like CI, Cairo, OpenGL, git , mercurial, MongoDB etc . Keep the great work and thanks for motivating me to use and learn Pharo, more and more. > Stef > > >

Nov. 24, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by stepharo

I suggest all interested parties to - review the code of skip - let him some time to improve - help if you want The goal of skip internship with us is to build a better code review system for Pharo. And we decided to use existing infrastructure instead of building our own seaside-based yet another server to maintain. Stef Le 23/11/15 16:25, Skip Lentz a Ã©crit : > Hi everyone, > > As part of my internship I am creating bindings to the GitHub API in > Pharo. > As a prototype and demo, I have created a small tool last week to do > some basic versioning, namely checking out a version, committing a > version and showing a log of commits along with a branch tree. > > Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png > > The repository of the bindings and the tool is here: > http://smalltalkhub.com/#!/~Balletie/GitHub > <http://smalltalkhub.com/#%21/%7EBalletie/GitHub> > To load the tool into your image, execute: > > (ConfigurationOfGitHub project version: #development) load: #tool > > Keep in mind that this is tied to GitHub, since internally it uses the > API. A nice side effect of this is that everything can be done > in-memory. That is, thereâs no local copy on the filesystem. One does > not even need git installed. > > That being said, feel free to take off with my prototype and make it > work with e.g. the LibGit bindings in Pharo. > > Known bug: > - When selecting a different repository from the dropdown while a > version is also selected in the log, one gets a DNU. To work around > this for the time being, just deselect the version before you switch > repositories. > > Let me know what you think and feel free to ask some questions. > > Skip

Nov. 24, 2015

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

by stepharo

+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 > <mailto:marcus.denker@inria.fr>>: > > > > On 22 Nov 2015, at 20:12, EuanM <euanmee(a)gmail.com > <mailto:euanmee@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 <mailto:marcus.denker@inria.fr>> wrote: > >> > >> On 20 Nov 2015, at 14:35, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > >> > >> > >> 2015-11-20 14:21 GMT+01:00 Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@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. 24, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Thierry Goubier

Hi Mariano, Le 22/11/2015 23:31, Mariano Martinez Peck a Ã©crit : > > ... > > You know what is funny? I run all AST-Tests-Core from Pharo and NONE > halt on #createBlockFor: ... > I even run all those from Refactoring-Tests-Core. > *So..it seems there is not tests that covers the usage of > #createBlockFor: :(* Ok. I'll have a scan of all the RB tests and add additional tests then. There is an issue John pointed to Nicolai and me that needs solving as well. > BTW, do you image other cases like this? > > > You mean storing those RB rules? I try to collect them if I see some > (or participate to), or remember where I see them. > > > No, I mean the compilation of block closures that would try to bind > "self". Anyway, I will search if I find more. Thanks. > I used to know where the RBRewriteTree chapter was in the Pharo > books, but it seems to have disappeared, so I have recreated a copy > that I'll try to update. > > > > Thanks, please share it with me when you made it because I could not > find it weeks ago. My fork of the Pharo for the enterprise book has it: https://github.com/ThierryGoubier/PharoForTheEnterprise-english But I don't have a CI building it yet. Thierry

Nov. 24, 2015