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

Re: [Pharo-dev] Open vs Closed issues visualised

by Marcus Denker

On 05 Dec 2013, at 10:50, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Does that mean we closed around 2000 issues since May ? yes. > And all the time there were around 100 issues opened ? > yes, and all of that difference was moving the issues from the unused cog issue tracker (which have seen 0 activity sinceâ¦). Else we would have less open issues than in May. Marcus

Dec. 5, 2013

Re: [Pharo-dev] Open vs Closed issues visualised

by ClÃ©ment Bera

Does that mean we closed around 2000 issues since May ? And all the time there were around 100 issues opened ? 2013/12/5 Marcus Denker <marcus.denker(a)inria.fr> > start is may this year... >

Dec. 5, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

On 05.12.2013, at 10:12, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 05 Dec 2013, at 7:48 , Max Leske <maxleske(a)gmail.com> wrote: > >> Thanks for the input. >> >> The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. >> >> Cheers, >> Max > > In my experience, the legacy solution for swapping binary/ascii writing to in-memory collections is using a (MultiByte)BinaryOrTextStream instead of a standard ReadWriteStream. Youâre right. I had thought about simply using RWBinaryOrTextStream instead of ReadStream in MemoryFileSystem but that felt like committing a crimeâ¦ :) > > Cheers, > Henry > > P.S. In fact, that class is pretty much the ultimate example of why the XTreams approach is superior. > It *looks* like itâs interchangeable with (MultiByte)FileStream, but the implementations are completely independent, and thus a subtle set of differences are bound to exist. (and do, but I canât remember exactly which atm) > Maintaining and bug fixing either is a nightmare, and introducing further divergence bugs in the long run is pretty much inevitable. > > Much better to composite singly implemented, single purpose wrappers streams on top of dumb terminals for each destination type to achieve desired input -> output transformations. > >

Dec. 5, 2013

Open vs Closed issues visualised

by Marcus Denker

start is may this year...

Dec. 5, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Henrik Johansen

On 05 Dec 2013, at 7:48 , Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the input. > > The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. > > Cheers, > Max In my experience, the legacy solution for swapping binary/ascii writing to in-memory collections is using a (MultiByte)BinaryOrTextStream instead of a standard ReadWriteStream. Cheers, Henry P.S. In fact, that class is pretty much the ultimate example of why the XTreams approach is superior. It *looks* like itâs interchangeable with (MultiByte)FileStream, but the implementations are completely independent, and thus a subtle set of differences are bound to exist. (and do, but I canât remember exactly which atm) Maintaining and bug fixing either is a nightmare, and introducing further divergence bugs in the long run is pretty much inevitable. Much better to composite singly implemented, single purpose wrappers streams on top of dumb terminals for each destination type to achieve desired input -> output transformations.

Dec. 5, 2013

[Issue tracker] Help for reviewing needed

by Marcus Denker

Hello, Many people submit lots of nice things, which is greatâ¦ but not many people look at the issues. https://pharo.fogbugz.com/f/filters/45/Review Help would be appreciated. Marcus

Dec. 5, 2013

Re: [Pharo-dev] Smalltalker meeting at Prague

by Pavel Krivanek

I am. -- Pavel 2013/12/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > I will be at Prague teaching from 9 to 13 december and we can organise a > Smalltalker gathering for example after > work. Tell me if you are interested. > > Stef >

Dec. 5, 2013

Re: [Pharo-dev] [Nautilus] Selecting package

by Roberto Minelli

Hi Stef, On Dec 5, 2013, at 8:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi Stef, >> >> I spoke with Esteban before, however thanks for the clarification. >> >> IMHO however the current structure is confusing, and names are misleading. The thing about packages, categories, namespaces and what not has always been not perfect for me, nor in Pharo nor in many other PLs. >> >> The way I would have done it, conceptually, independently of Nautilus, Monticello and whatever else is the following: >> >> A package is a container used to structure a project, it contains >> - zero or more classes >> - zero or more other packages > > this is the world of "bisounours" welcome to reality. > >> This model would be damn simple, and consistent > > and not covering what we want :) Well, then I do not understand what you want ;) The to models are equivalent in âpower".. > >> and you should not explicitly think about how to structure your things.. >> I can create a package âDFlowâ put some classes, then I create another package 'DFlow-Coreâ which *automatically* goes into the âDFlowâ package because it starts with the same prefix plus the dash, > > we do not want to rely on naming conventions. Now this has been discussed during a couple of years. so look for it and esteban spent 5 months on it so do you think that > it was that simple? I never said it is simple. Namespaces, packages & co. is something that no PL has ever solved in a perfect way. > >> which is somewhat our convention, right? And however we can think of mechanisms to cope with other kind of automatic sub-packaging and/or manual removal (in case our heuristics fail). > > I can think to a lot of nice solutions but after you should have solutions > - scale > - migrate > - fit people practices > >> >> For me having packages, groups, tags, and categories is too much. > > > We are killing categories and I would have removed it completely (not having tags) but people and practice showed that they were needed > Then groups is just so handy I use that all the time. > Then I do not understand why you bother. The point is that each of these objects should reply polymorphically to the same message > probably allClasses, extensions, â¦ if this is not the case then this is also easy we should add these messages. > > If you do not have specific entities you are forced to have conditionals and it starts to get ugy and not modular so I do not see your problems. I am not saying the implementation is not clean or it is implemented in a bad way. I am saying that I *personally* do not like this design. > OO design is your friend but it requires time to deeply understand it. Itâs not about understanding the OO design. Itâs clear what you guys did and implemented. The thing that bugs me is the âconceptual modelâ behind the OO-design. Cheers, R

Dec. 5, 2013

Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me

by StÃ©phane Ducasse

Hi stefan this is strange why would you be the only one that cannot commit slices? Can you do a controlled experience? Stef On Dec 4, 2013, at 8:56 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hereâs a new slice, the corresponding packages are in the inbox. > <SLICE-Issue-12324-There-should-be-no-class-side-implementations-of-packages-except-for-ClassDescription-StephanEggermont.2.mcz>

Dec. 5, 2013

Re: [Pharo-dev] Opal hook?

by StÃ©phane Ducasse

Hi nicolas > I forgot to add that the OCUndeclaredVariableWarning was already handled at semantic analysis. > Do you suggest that default behavior should be to handle and retry instead of handle and return? I suggest that we can define what is the behavior of handling an exceptional cases. > One way to achieve what you are asking would be to initialize the Undeclared entry to some kind of ProtoObject that does not understand anything and rethrow a OCUndeclaredVariableWarning instead of a MessageNotUnderstood... (very uneasy to debug, since the Debugger itself is querying the receiver etc... - unless Debugger is using basic mirror primitives) we should be able to say: when you encounter an undefined do that when you enconter a syntax error do that We should have a list of hooks and exceptional situations and be able to define the actions we want to be performed. This way the compiler would not depend on the UI also :). I love these "layers" from the past. When you have a UI then you specify new actions which involves popup and other niceties. and in particular exception should not hardcode the popup of menu and other UI related things. So this is not linked to the phases of compilation, this is linked to offering customisable error. Stef > 2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Steph, each time you want to evaluate something, do you agree that this involves > - a parse phase of the expression you want to evaluate to create an AST > - a code generation phase from AST -> bytecodes to generate a CompiledMethod > - the evaluation phase itself which evaluates above CompiledMethod with appropriate receiver (nil generally) > > I didn't check OPAL, but do you agree that the semantic analysis determining which are those variables you called {'AnUnknownClass'. 'OCUndeclaredVariableWarning'. 'self'} and how to bind them, must happen somewhere between AST and CompiledMethod creation? > > So if there is a semantic exception, like UndeclaredVariable, how would the CompiledMethod be generated in the first place? > If it's not generated, how would it be executed? > If it's not executed, how would the message on:do: be sent to a block with 2 arguments? > > Unless you suggest to attempt executing a ParseTree which is known to be defectuous... > > 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> AnUnknownClass subclass: #Adaptor1Example >> instanceVariableNames: 'customers accountID address name phoneNumber' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Examples-Cookbook' >> >> executes the default action for OCUndeclaredVariableWarning, which is opening a pop-up titled: "Unknown variable ...". Here the error is raised at compilation time, therefore it would have no effect to wrap this with a #on:do: > > I do not understand why if an exception is raised why I cannot trap it. > > [AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook'] on: OCUndeclaredVariableWarning do: [ self halt.] does not halt. > > The fact that is is at compilation time does not mean anything to me. So why? I'm totally confused by this bad and unexpected behavior. > Do you imply that the warning is already trapped and that I cannot take precedence? Probably but this has nothing to do with compilation time. > > Then to me OCSemanticWarning should be enhanced so that we do not get these silly menus. An exception should work and clients should be able to customise > it to (for example introduce menu and dialog with the users but they should not be the only default. > We see again this plague of interactive environment not being rethought in the 2013 age. > > defaultAction > > self errorNotification ifFalse: [ ^nil ]. > ^self openMenuIn: > [:labels :lines :caption | > UIManager default chooseFrom: labels lines: lines title: caption] > > but that we could specify the action to be executed instead. > > > to me CompilerException should have nothing to do with UI and popup. Then we should be able to pass objects that knows how to handle > the errors in interactive way or not. > > As a clear example, this is just bad that each time we want to change the UI message we have to change the compiler exception. > ugly at wish. > > I have no cycle to fix that now. I will check if I can get something in UndefinedObject so that I can continue to work on my task. > > Stef > > > >> [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example >> instanceVariableNames: ''customers accountID address name phoneNumber'' >> classVariableNames: '''' >> poolDictionaries: '''' >> category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] >> >> Here we catch the error, and you can handle it. >> Now it is not easily possible to resume the error, because you want a global instead and Opal expects a temp (there are way to resume but with very deep stack manipulation that I do not want to show to young pharoers present on this mailing list). So the best is to retry it. One solution is therefore: >> >> [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example >> instanceVariableNames: ''customers accountID address phoneNumber'' >> classVariableNames: '''' >> poolDictionaries: '''' >> category: ''Examples-Cookbook''' ] >> on: OCSemanticWarning do: [ :e | >> Smalltalk at: e node name put: StubRootClass. >> e retry ] >> >> with e node name answering #AnUnknownClass here. >> Now you need to make sure that the exception block is executed for the case of a missing superclass and not something else or you will end up creating loads of globals. >> >> The exception block should be something similar to: >> >> [ :e | >> e node name first isUppercase and: [ "some condition" ] ifTrue: [ >> Smalltalk at: e node name put: StubRootClass. >> ^ e retry ]. >> e pass ] >> >> How to undefined and OCUndeclaredVariableWarning relate? >> >> In your case, while loading from Monticello the code is compiled and evaluated in non interactive mode. Therefore it cannot trigger the default action of OCUndeclaredVariableWarning which is a UI event. So it sets by default the unknown global to: >> >> Undeclared at: varName asSymbol put: nil. >> OCUndeclaredVariable new name: varName asSymbol >> >> in: OCUndeclaredVariableWarning >>defaultAction >> >> which then later triggers the code in UndefinedObject. > > >

Dec. 5, 2013