May 2013 - Pharo-dev - lists.pharo.org

About the Mailinglist debacle...

by Marcus Denker

Hello, So now that everything is workingâ¦ sorry for the mess. We should have left the gforge infrastructure the last time we had a multi-day problem, not wait till we get it again. I think this will be my new principle: second real problem -> I leave. No discussions. We already saw with the jenkins story just how deadly bad infrastructure is. So what happened was that last Tuesday, the lists (all lists of gforge) stopped delivering. Why is not clear, seemingly it was not gforge itself but the upstream servers did not deliver. Whatever. What is clear is that it was completely unclear how long this would take, and that we needed a solution after nearly a week of waiting. So we decided to move the lists. Of course with the old lists down, this was harder than normal (even involved parsing the html to get the subscribersâ¦) but that is not important. Now the problem its hat Mailman does not distinguish between people that unsubscribe, and those turning off delivery. So there where just a lot of people listed with "nomail (U)", What to do? It was clear that we can't just subscribe lots of people to a list that they *actively* unsubscribed. So the only option was to skip those by -> unsubscribing them from the old list -> then get the list of subscribers -> put that in the new list. The only people that will see a bad effect are those using e.g nabble to read the list. But those would see the new mails, too. The only problem they have is if the want to send. So not *that* of a big deal. It seems that we got quite some false positive subscribers anyway in the form of people who filtered the mails and then with the new list the filter did not work and they suddenly saw mails of a long forgotten list. We even had the case of people who where "nomail (U)", yet they did get mails delivered. How that can possibly work, I have no clue *at all*. What else is missing (and on my TODO since Sunday/Monday, sorry for not yet acting on it): -> lists.pharo.org has an empty page and needs to point to the list of the lists inttead -> the archive needs to be moved from the old jenkins. -> the (incomplete) archive of the new lists is not working since I put it as public. Soâ¦ maybe it would have been better to just wait until gforge works again and then moveâ¦ but it was just far too long already and not clear when it would be working again. Marcus

May 15, 2013

Re: [Pharo-dev] Making ASTInterpreter work with opal bindings

by ClÃ©ment Bera

2013/5/15 Guillermo Polito <guillermopolito(a)gmail.com> > > > > On Wed, May 15, 2013 at 3:40 PM, ClÃ©ment Bera <clement.bera(a)inria.fr>wrote: > >> Sorry with the strike and no metro I cannot be at INRIA today. I'm at >> Marcus right now we will have a look at your slice now :) >> >> I don't know why this morning I hadn't received yet your mails from >> yesterday. >> >> 2013/5/14 Guillermo Polito <guillermopolito(a)gmail.com> >> >>> >>> On Tue, May 14, 2013 at 1:03 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: >>> >>>> Hey Guille, >>>> >>>> To debug AST-interpreter there is a specific AIContextInspector. What >>>> you can do is just to inspect in the debugger the latest AIContext created >>>> by the AST-interpreter and you should see the stack of AIContext in the >>>> inspector. It is not perfect but it helps a lot. There is also the >>>> AST-Debugger but it is just a prototype so you can hardly use it. >>>> >>> >>> Buu, how do I get the ASTDebugger? Maybe I can give it a try... >>> >> >> AST-Debugger is at Smalltalkhub user : dh83 project : ast-interpreter >> package AST-debugger there is no config. But it's just a quick prototype, >> there is some work to do. To try you should copy AST-debugger test in >> workspace (in test it does not works because of problem with test thread / >> UI thread) and then run. The into button works a little, the other not, but >> the stack and inspectors works. >> >> > Will try, tx! > > >> >>> >>>> >>>> testEnsureTricky is the one that checks ensure nested in the on:do: >>>> works correctly. Basically it checks when you unwind the context up to the >>>> exception handler that you executes the ensure blocks code. It's kind of >>>> the trickiest one to fix :/. In the exception chapter of Deep into Pharo I >>>> added a section somewhere in Exception implementation about that, it might >>>> help you to read it. >>>> >>>> Take care, AST-interpreter tests might not be enough. You should check >>>> the console output of the AST-interpreter-regression build too. (here : >>>> https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) >>>> But it is failing since some new updates in Pharo 3.0 ... >>>> >>> >>> I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. >>> What does this job test/do? We can add that to the description :) >>> >> >> This test runs all the Pharo Kernel tests with the AST-interpreter. Then >> you can guarantee the AST-interpreter can interpret the whole Pharo Kernel >> suite, which is much more than just AST-interpreter tests. >> > > I did, all green :). > This is not possible there is primitive:error:code: that fails. The problem is that the result is displayed per package. So you have to click 'full log' then check the 8 blue text, and check there is no [FAIL] before ... But if the build finishes it is already something. Marcus answered for the problem with the binding. > > >> >> >>> >>> Anyway, I'm loading the same as the job, so I can test the slice locally >>> in my machine :) >>> >>> >>>> >>>> Are you committing on the AST-interpreter repository or on Pharo >>>> directly ? >>>> >>> >>> Pharo... Should I commit to the other repo? Don't have grants =^). >>> >> >> There is currently no dev any more on AST-interpreter but it would be >> nice to commit to the other repo first for the 2 jenkins jobs to run. Ask >> Camillo to have the rights to write on it. >> > > Camillo? Can I??? > > >> >> >>> >>> >>>> I don't think there are but there might be some fixes already on the >>>> dev branch > Smalltalkhub user: dh83 project: ast-interpreter >>>> >>> >>> Will check. Actually, I just loaded bleeding edge + merged my slice, and >>> the same test still fails. >>> >>> >>>> >>>> I would like to work on Opal test this afternoon but if you come to >>>> lille this week (not today because there is the strike) we can have a look >>>> together. >>>> >>> >>> Tomorrow! >>> >> >> Not possible there is still the strike... Are you at INRIA ? >> > > Nope. Douai :( > > >> >>> >>>> For M4te I've also fixed some stuff in Hz on the m4te repo (basically >>>> compatibility with the new RB visitor API) it might be nice to commit it on >>>> your repo too. >>>> >>> >>> cool :) >>> >>> >>>> >>>> See you, >>>> >>>> >>>> >>>> 2013/5/14 Guillermo Polito <guillermopolito(a)gmail.com> >>>> >>>>> Right now, in the image there exist two ways to annotate an AST: >>>>> - the Opal way >>>>> - the RB Way >>>>> >>>>> We should simplify that by having only one. So far, the only user of >>>>> the RB bindings is the ASTInterpreter + the RB tests. >>>>> >>>>> So, I prepared a slice and issue [1], with the following details >>>>> >>>>> - annotate ast using opal annotator >>>>> - extended OCBindings to read and write from an AST interpreter >>>>> - not yet made a difference between arg nodes with a different class >>>>> (just put an if) >>>>> - i didnt add inst vars into the opal bindings for the binding->node >>>>> relation as in RB, I send the node as a parameter >>>>> - I had to adapt the #compile: into ASTInterpreter because >>>>> - opal does not annotate other than method nodes >>>>> - undeclared variables raised warnings, not errors >>>>> >>>>> There is one problem yet, I have only one failing test: >>>>> #testEnsureTricky. I don't understand yet why it is failing and debugging >>>>> it is pretty complex :). So any help is welcome in reviewing the changes. >>>>> >>>>> Guille >>>>> >>>>> [1] >>>>> https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bin… >>>>> >>>> >>>> >>>> >>>> -- >>>> ClÃ©ment BÃ©ra >>>> Mate Virtual Machine Engineer >>>> BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq* >>>> >>> >>> >> >> >> -- >> ClÃ©ment BÃ©ra >> Mate Virtual Machine Engineer >> BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq* >> > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

May 15, 2013

[update 3.0] #30133

by Marcus Denker

30133 ----- 10618 loadin latest OpalCompilerTests makes CompilerTests dirty https://pharo.fogbugz.com/f/cases/10618 + load latest Opal Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/CompilerTests-MarcusDenker.15…

May 15, 2013

Re: [Pharo-dev] Making ASTInterpreter work with opal bindings

by Marcus Denker

On May 15, 2013, at 3:41 PM, ClÃ©ment Bera <clement.bera(a)inria.fr> wrote: > Sorry with the strike and no metro I cannot be at INRIA today. I'm at Marcus right now we will have a look at your slice now :) > So we lookedâ¦ and there is a problem with readWith: anInterpreter inNode: aVariableNode self isArg ifTrue: [ | definingScope argIndex | definingScope := aVariableNode scope lookupScopeForVar: aVariableNode name. argIndex := definingScope node argumentNames indexOf: name. ^ anInterpreter readArgumentAt: argIndex node: aVariableNode ]. "If it is not an arg, it is a normal temporary" ^ anInterpreter readTemporaryAt: -1 named: name When generating byte code with closures the way they are implemented (with escaping variables allocated in Arrays on the heap), we can not assign any meaningful index to temps. (there is an index ivar, but this needs to be cleaned up). Now temps and args are modelled the same, but all kinds indexes that you could calculate are meaningless. Especially argIndex := definingScope node argumentNames indexOf: name. does not need to be consistent with the actual position of the argâ¦ in edge cases. So we need to think about thisâ¦ maybe introducing a OCArgVariable (with index) is the only way to do it. Marcus

May 15, 2013

Re: [Pharo-dev] Fwd: Registering to the issue tracker

by Clara Allende

just like that? Ok, I will :) thanks a lot :D On 15 May 2013 11:34, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Remove the . in your email adress ;-) > > Regards, > > On Wed, May 15, 2013 at 4:29 PM, Clara Allende <clari.allende(a)gmail.com> > wrote: > > Hi folks, I wanted to register to the new issue tracker via Penelope and > I'm > > getting an "Invalid email address"... could someone please add me? Or > point > > me in the right direction? > > > > thanks in advance! > > > > Cheers > > Clari > > > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

May 15, 2013

Re: [Pharo-dev] Fwd: Registering to the issue tracker

by Serge Stinckwich

Remove the . in your email adress ;-) Regards, On Wed, May 15, 2013 at 4:29 PM, Clara Allende <clari.allende(a)gmail.com> wrote: > Hi folks, I wanted to register to the new issue tracker via Penelope and I'm > getting an "Invalid email address"... could someone please add me? Or point > me in the right direction? > > thanks in advance! > > Cheers > Clari > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 15, 2013

Fwd: Registering to the issue tracker

by Clara Allende

Hi folks, I wanted to register to the new issue tracker via Penelope and I'm getting an "Invalid email address"... could someone please add me? Or point me in the right direction? thanks in advance! Cheers Clari

May 15, 2013

Re: [Pharo-dev] Making ASTInterpreter work with opal bindings

by Guillermo Polito

On Wed, May 15, 2013 at 3:40 PM, ClÃ©ment Bera <clement.bera(a)inria.fr> wrote: > Sorry with the strike and no metro I cannot be at INRIA today. I'm at > Marcus right now we will have a look at your slice now :) > > I don't know why this morning I hadn't received yet your mails from > yesterday. > > 2013/5/14 Guillermo Polito <guillermopolito(a)gmail.com> > >> >> On Tue, May 14, 2013 at 1:03 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: >> >>> Hey Guille, >>> >>> To debug AST-interpreter there is a specific AIContextInspector. What >>> you can do is just to inspect in the debugger the latest AIContext created >>> by the AST-interpreter and you should see the stack of AIContext in the >>> inspector. It is not perfect but it helps a lot. There is also the >>> AST-Debugger but it is just a prototype so you can hardly use it. >>> >> >> Buu, how do I get the ASTDebugger? Maybe I can give it a try... >> > > AST-Debugger is at Smalltalkhub user : dh83 project : ast-interpreter > package AST-debugger there is no config. But it's just a quick prototype, > there is some work to do. To try you should copy AST-debugger test in > workspace (in test it does not works because of problem with test thread / > UI thread) and then run. The into button works a little, the other not, but > the stack and inspectors works. > > Will try, tx! > >> >>> >>> testEnsureTricky is the one that checks ensure nested in the on:do: >>> works correctly. Basically it checks when you unwind the context up to the >>> exception handler that you executes the ensure blocks code. It's kind of >>> the trickiest one to fix :/. In the exception chapter of Deep into Pharo I >>> added a section somewhere in Exception implementation about that, it might >>> help you to read it. >>> >>> Take care, AST-interpreter tests might not be enough. You should check >>> the console output of the AST-interpreter-regression build too. (here : >>> https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But >>> it is failing since some new updates in Pharo 3.0 ... >>> >> >> I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. >> What does this job test/do? We can add that to the description :) >> > > This test runs all the Pharo Kernel tests with the AST-interpreter. Then > you can guarantee the AST-interpreter can interpret the whole Pharo Kernel > suite, which is much more than just AST-interpreter tests. > I did, all green :). > > >> >> Anyway, I'm loading the same as the job, so I can test the slice locally >> in my machine :) >> >> >>> >>> Are you committing on the AST-interpreter repository or on Pharo >>> directly ? >>> >> >> Pharo... Should I commit to the other repo? Don't have grants =^). >> > > There is currently no dev any more on AST-interpreter but it would be nice > to commit to the other repo first for the 2 jenkins jobs to run. Ask > Camillo to have the rights to write on it. > Camillo? Can I??? > > >> >> >>> I don't think there are but there might be some fixes already on the dev >>> branch > Smalltalkhub user: dh83 project: ast-interpreter >>> >> >> Will check. Actually, I just loaded bleeding edge + merged my slice, and >> the same test still fails. >> >> >>> >>> I would like to work on Opal test this afternoon but if you come to >>> lille this week (not today because there is the strike) we can have a look >>> together. >>> >> >> Tomorrow! >> > > Not possible there is still the strike... Are you at INRIA ? > Nope. Douai :( > >> >>> For M4te I've also fixed some stuff in Hz on the m4te repo (basically >>> compatibility with the new RB visitor API) it might be nice to commit it on >>> your repo too. >>> >> >> cool :) >> >> >>> >>> See you, >>> >>> >>> >>> 2013/5/14 Guillermo Polito <guillermopolito(a)gmail.com> >>> >>>> Right now, in the image there exist two ways to annotate an AST: >>>> - the Opal way >>>> - the RB Way >>>> >>>> We should simplify that by having only one. So far, the only user of >>>> the RB bindings is the ASTInterpreter + the RB tests. >>>> >>>> So, I prepared a slice and issue [1], with the following details >>>> >>>> - annotate ast using opal annotator >>>> - extended OCBindings to read and write from an AST interpreter >>>> - not yet made a difference between arg nodes with a different class >>>> (just put an if) >>>> - i didnt add inst vars into the opal bindings for the binding->node >>>> relation as in RB, I send the node as a parameter >>>> - I had to adapt the #compile: into ASTInterpreter because >>>> - opal does not annotate other than method nodes >>>> - undeclared variables raised warnings, not errors >>>> >>>> There is one problem yet, I have only one failing test: >>>> #testEnsureTricky. I don't understand yet why it is failing and debugging >>>> it is pretty complex :). So any help is welcome in reviewing the changes. >>>> >>>> Guille >>>> >>>> [1] >>>> https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bin… >>>> >>> >>> >>> >>> -- >>> ClÃ©ment BÃ©ra >>> Mate Virtual Machine Engineer >>> BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq* >>> >> >> > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq* >

May 15, 2013

Re: [Pharo-dev] [Pharo-project] Fwd: suggestions for Smart Suggestions

by Gisela Decuzzi

2013/5/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi gisela. > > - When selecting a literal we should be able to get extract method. > Done Also fixed the icons and not offering the extract local for Sequences nodes with more than one sentence. (The slice is 10629) and version 1.1 > > - when I select an instance variable in the class definition I cannot > apply refactoringâ¦. yes I know this is because this is a STRINGâ¦ > What a pain. > Agree! > > Stef > > >

May 15, 2013

Re: [Pharo-dev] Refactoring API and the AST Nodes

by stephane ducasse

It is nice that you think about that :). May be this is just that we have different contexts of use and that we should improve the API by supporting such scenario. Stef > I've been thinking about this... because the refactoring api can be a pain to handle (at least for me) in some cases, specially when I'm working with an AST node... because in the node it's all (or almost all) the information needed for the api and I started to ask me... why I'm always opening the node to extract all the strings just to use the Refactorings? > > I don't like to do that, and I think that time to time we have that problem and ended repeating code... I was thinking in change the refactoring API to accept an AST node, but it's not true that we have the node in the hand all the time we want to use it, and adding more entry points could complex the api. Also if we convert a node in a model for the refactors there are some cases where the information isn't complete in the node, by example to rename a variable you need the new name... and that is not present in the node but needed for the refactor... so is not that simple to make them an inocent model... > > Then I thought that I can use a new object that takes the node, and creates the refactors needed (similar to NautilusRefactoring using an ast node), but in this model I think that we are doing yet another work around and not a real solution... > > The other day Guille points me that maybe I should think that the refactoring API is kind of ok... and maybe the nodes could give me the refactors or an almost configured refactor... since they have (almost all) the information. > > So... I was thinking in this approach, it could be a solution to all the strings handling, and it kind of make sense that the node knows the refactors that apllies and how to construct it with the information needed. > > A number of ideas... and I would like to discuss about them, maybe here is someone who has the same problem and arrived to a different solution, so I would like to exchange opinions and improve that part that I think we are working around but not solving :( > > > >

May 15, 2013