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

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Marcus Denker

On 23 Nov 2013, at 21:25, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-11-23, at 11:02, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > >> Le 23/11/2013 09:51, Camillo Bruni a Ã©crit : >>> opened https://pharo.fogbugz.com/f/cases/12229/XML-Tools-improvement otherwise these changes are as good as lost. >>> sending mcz via mail is from the last century. >> >> Hello >> >> In the welcome page of the bug tracker, add a page explaining how to >> create by yourself an account. > > It is all there: https://pharo.fogbugz.com/default.asp?W41 > > I was even so lazy that I made a video ;) since there are so many nasty steps > involved that I don't think text will do it. and it should be noted that the scheme we use is not the way it is because we think itâs perfect. This is really strange that people always pre-suppose that whatever is done is done with indefinite resources and therefore by definition exactly what was wanted. To the contrary: we just make it up as we go along, with very limited resources, sometimes doing wrong decisions.. and we will slowly improve. And no, just stopping until the process is perfect is *not* they way to go. This will just lead to nothing happening, not to perfection. Marcus

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Camillo Bruni

On 2013-11-23, at 20:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On 23 Nov 2013, at 20:44, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: >> Le 23/11/2013 19:19, Hilaire Fernandes a Ã©crit : >>> Le 23/11/2013 19:05, Sean P. DeNigris a Ã©crit : >>>> But seriously if this is not clear, how do we improve it? >>>> >>> >>> Make it work. It never worked for me, I keep trying then give up, >>> thinking about a temporary failure, then doing other business. >>> I don't understand what the monkey really want but it is not nice with >>> me. So I guess I miss something that should be documented. >>> >>> Hilaire >>> >>> >> >> So registering on Pharo tracker *never* worked for me, since I try, >> before the summer. >> > > In the end I think is was a mistake to use fogbugz. For sure itâs nice for companies, but > for open sourse projects it just does not work with a closed bug tracker. But I get the impression that everybody wants to submit fixes their way and assume that things are resolved in another way. There is quite a system behind everything which is documented and well described (of course nobody ever read it...): https://pharo.fogbugz.com/default.asp?W65 I currently see 4 big problems: 1. the password reset mail is not sent automatically (very confusing) 2. you need 2 accounts (once for fogbugz and once for smalltalkhub) 3. there are no public inboxes on smalltalkhub (requires another bothersome step to add people manually) 4. submitting a slice from the image requires the previous 3 steps to be completed upfront It is close to impossible to describe that accurately in text, that's why I opted for a video which takes some time, but should include all the above steps. I am pretty sure that if you follow the video step by step you will get access without problems. If not, I can update the instructions there.

Nov. 23, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by Esteban A. Maringolo

2013/11/23 Eliot Miranda <eliot.miranda(a)gmail.com> > > On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> imo, a better term to use for it would be 'private class' , because anonymous is a bit fuzzy. > > > I disagree. Anonymous classes is the term that has been used for over two decades. It means, literally, a class that has no name because it is not in Smalltalk (or in a top-level environment if the dialect has namespaces). This is not at all fuzzy. Private class means something quite different, a class that is private to some environment, e.g. a class nested within another class as occurs in SmalltalkAgents or Newspeak. +1 Anonymous = without name. There's not much to add to it. Regards,

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Camillo Bruni

On 2013-11-23, at 11:02, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 23/11/2013 09:51, Camillo Bruni a Ã©crit : >> opened https://pharo.fogbugz.com/f/cases/12229/XML-Tools-improvement otherwise these changes are as good as lost. >> sending mcz via mail is from the last century. > > Hello > > In the welcome page of the bug tracker, add a page explaining how to > create by yourself an account. It is all there: https://pharo.fogbugz.com/default.asp?W41 I was even so lazy that I made a video ;) since there are so many nasty steps involved that I don't think text will do it.

Nov. 23, 2013

[pharo-project/pharo-core] c6f5c7: 30591

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: c6f5c752ffcb1ca34877fae05114ecb124726166 https://github.com/pharo-project/pharo-core/commit/c6f5c752ffcb1ca34877fae0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-23 (Sat, 23 Nov 2013) Changed paths: R Compiler.package/Compiler.class/class/accessing/decompilerClass.st R Compiler.package/Decompiler.class/instance/public access/decompile_in_.st A Deprecated30.package/extension/Compiler/class/decompilerClass.st A Deprecated30.package/extension/Decompiler/instance/decompile_in_.st A Deprecated30.package/extension/Object/instance/triggerEvent_ifNotHandled_.st A Deprecated30.package/extension/Object/instance/triggerEvent_withArguments_ifNotHandled_.st A Deprecated30.package/extension/Object/instance/triggerEvent_with_ifNotHandled_.st A Deprecated30.package/extension/Point/instance/rect_.st A Deprecated30.package/extension/Rectangle/instance/outsetBy_.st R Kernel.package/Object.class/instance/deprecated30/triggerEvent_ifNotHandled_.st R Kernel.package/Object.class/instance/deprecated30/triggerEvent_withArguments_ifNotHandled_.st R Kernel.package/Object.class/instance/deprecated30/triggerEvent_with_ifNotHandled_.st R Kernel.package/Point.class/instance/converting/rect_.st R Kernel.package/Rectangle.class/instance/rectangle functions/outsetBy_.st M Morphic-Base.package/MorphTreeListManager.class/instance/mouse managing/mouseDown_on_.st M Morphic-Base.package/MorphTreeMorph.class/instance/expanding-collapsing/expandRoots.st M Morphic-Base.package/MorphTreeMorph.class/instance/submorphs-add%2Fremove/addMorphsAfter_fromCollection_.st M Morphic-Base.package/MorphTreeMorph.class/instance/updating/noteRemovalOfAll_.st A Morphic-Base.package/MorphTreeNodeModel.class/instance/dependents/addDependent_.st A Morphic-Base.package/MorphTreeNodeModel.class/instance/protocol/selected.st A Morphic-Base.package/MorphTreeNodeModel.class/instance/testing/hasContentToShow.st A Morphic-Base.package/MorphTreeNodeModel.class/instance/testing/isPartialMatch.st M Morphic-Base.package/MorphTreeNodeMorph.class/instance/accessing/selected_.st M Morphic-Base.package/MorphTreeNodeMorph.class/instance/drawing/drawCheckOn_in_.st M Morphic-Base.package/MorphTreeNodeMorph.class/instance/initialization/initWithContents_prior_forList_indentLevel_.st A Morphic-Base.package/MorphTreeNodeMorph.class/instance/testing/hasContentToShow.st A Morphic-Base.package/MorphTreeNodeMorph.class/instance/testing/isPartialMatch.st A Morphic-Base.package/MorphTreeNodeMorph.class/instance/updating/update_.st M Polymorph-Widgets.package/CheckboxMorph.class/instance/initialization/initialize.st M Polymorph-Widgets.package/DropListItem.class/definition.st A Polymorph-Widgets.package/DropListItem.class/instance/accessing/icon.st A Polymorph-Widgets.package/DropListItem.class/instance/accessing/icon_.st M Polymorph-Widgets.package/DropListItem.class/instance/initialization/initialize.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script246.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30591.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30591 12225 Enhancement in MorphTreeMorph https://pharo.fogbugz.com/f/cases/12225 12226 Minor additions https://pharo.fogbugz.com/f/cases/12226 12224 Move Kernel deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/12224 12228 Move Compiler deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/12228 http://files.pharo.org/image/30/30591.zip

Nov. 23, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30591 Home: https://github.com/pharo-project/pharo-core

Nov. 23, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by HernÃ¡n Morales Durand

Hi Camille, What is an anonymous class for you? because it could refer to a lightweight class or a metaclass... Cheers, HernÃ¡n El 22/11/2013 12:04, Camille Teruel escribiÃ³: > Hi everyone, > > With Esteban, we bumped into a problem with anonymous subclasses and the slot class builder. > The problem is that once an anonymous class is created is not possible to modify it. > Here is the problem: > For creating an anonymous class with the new class builder API you do something like: > > myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | > classBuilder > superclass: Object; > name: #MyAnonymousClass; > .... ] > > What happens is that the class builder asks the class installer if the class named #MyAnonymousClass exists or not to know if this a class to be created or to be modified. > Here, the strategy of the anonymous class installer is to always answer no. So ok, now you have you're anonymous class. > But what happens when you do something like: > > myAnonymousClass addInstVarNamed: #newIV > > Since the class has no clue of what class installer was used to create it, it instantiate a new one, and a PharoClassInstaller ! > This new class installer then says to the class builder that there is no class named MyAnonymousClass so it creates it! And it install it in the system dictionary! > And myAnonymousClass is not modified. > > So there is several problem here: > - a class doesn't know which class installer was used to create it > - even if the class would know that, the anonymous class installer would always say that it doesn't know it and a new class would be created > > So one possible solution for that is to have one class installer per environment (so add one iv in SystemDictionary right now), like that a class would know what class installer was used to create it. > What would happen then is that you don't create anonymous classes anymore, that is to say a class not installed in any environment, but instead you create a class that exist in an environment separated from the system dictionary. > > What do you think? > > > . >

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Marcus Denker

On 23 Nov 2013, at 20:44, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 23/11/2013 19:19, Hilaire Fernandes a Ã©crit : >> Le 23/11/2013 19:05, Sean P. DeNigris a Ã©crit : >>> But seriously if this is not clear, how do we improve it? >>> >> >> Make it work. It never worked for me, I keep trying then give up, >> thinking about a temporary failure, then doing other business. >> I don't understand what the monkey really want but it is not nice with >> me. So I guess I miss something that should be documented. >> >> Hilaire >> >> > > So registering on Pharo tracker *never* worked for me, since I try, > before the summer. > In the end I think is was a mistake to use fogbugz. For sure itâs nice for companies, but for open sourse projects it just does not work with a closed bug tracker. Now the question is what is the effort to move to yet another one? Marcus

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Hilaire Fernandes

Le 23/11/2013 19:19, Hilaire Fernandes a Ã©crit : > Le 23/11/2013 19:05, Sean P. DeNigris a Ã©crit : >> But seriously if this is not clear, how do we improve it? >> > > Make it work. It never worked for me, I keep trying then give up, > thinking about a temporary failure, then doing other business. > I don't understand what the monkey really want but it is not nice with > me. So I guess I miss something that should be documented. > > Hilaire > > So registering on Pharo tracker *never* worked for me, since I try, before the summer. Hilaire -- Dr. Geo http://drgeo.eu

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by HernÃ¡n Morales Durand

El 23/11/2013 5:51, Camillo Bruni escribiÃ³: > opened https://pharo.fogbugz.com/f/cases/12229/XML-Tools-improvement otherwise these changes are as good as lost. > sending mcz via mail is from the last century. > Maybe, but some of us are attending 30 requirements not related with Pharo and do not have time to fill the bug cycle. HernÃ¡n > On 2013-11-23, at 09:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> No time so fr to handle it. >> >> Stef >> >> Begin forwarded message: >> >>> From: "monty" <monty.os(a)engineer.com> >>> Subject: Patches for Pharo packages you are maintaining >>> Date: November 21, 2013 3:14:25 AM GMT+01:00 >>> To: stephane.ducasse(a)inria.fr >>> >>> Prof. Stef, I have produced updates to the XML-Parser, XML-Parser-Testing, and XML-Writer-Core packages you are maintaining. >>> >>> These updates add validation against internal and external DTDs, proper replacement of general and parameter entites, customizable resolution of external parsed entities using Zinc and FileSystem, awareness of notations and unparsed entities, preservation of the internal DTD subset by the DOM parser (so printing a parsed doc with a DTD will produce approximately what was input), line numbers reporting in error messages, and better well-formed and validity constraints. >>> >>> I had to largely rewrite the tokenizer to make everything work, but I followed the spec closely, and it is about the same speed as long as there is no DTD to validate against. >>> >>> One problem is that while the tests I added and the existing tests all pass, for some reason helper messages in some test classes starting with "should" (in the style of should:raise:) are being interpreted as tests and run by TestRuner, even though they don't begin with "test" and take arguments! This is possibly a bug in TestRunner. >>> >>> Another problem is that there are so many deprecated methods cluttering up classes, some of which have been deprecated for years! It is confusing and hard to see which methods to use just by browsing the protocols. I would really suggest using this code to get rid of the XML-Parser methods that have been deprecated for at least a year: >>> >>> expiry := 1 year. >>> (SystemNavigation default allClassesInPackageNamed: 'XML-Parser') >>> do: [:class | >>> class selectors do: [:selector | | compiledMethod timeStamp | >>> compiledMethod := class compiledMethodAt: selector. >>> timeStamp := compiledMethod timeStamp copyAfter: Character space. >>> (compiledMethod isDeprecated >>> and: [(DateAndTime now - (DateAndTime fromString: timeStamp)) > expiry]) >>> ifTrue: [class removeSelector: selector]]]. >>> >>> I ran and checked it myself and it doesn't break anything. Running the above with XML-Writer-Core might not be a bad idea either. >>> >>> I also updated BitmapCharacterSet to use less memory. >> <XML-Writer-Core-monty.5.mcz> >> <XML-Tests-Parser-monty.27.mcz> >> <XML-Parser-monty.173.mcz> >> <Collections-BitmapCharacterSet-Anonymous.6.mcz> >> <Collections-BitmapCharacterSet-Anonymous.6.mcz> >> >

Nov. 23, 2013