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

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Pavel Krivanek

2017-05-09 18:44 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > [redirected from pharo-gsoc to pharo-dev] > > On Tue, May 9, 2017 at 7:36 AM, Oleksandr Zaytsev <olk.zaytsev(a)gmail.com> > wrote: > > A. Improved my fix of this case: https://pharo.fogbugz.com/f/cases/19396, > as > > suggested by Ben Coman, and created a slice for it (I think it works > like PR > > in Pharo - correct me if I'm wrong). > > Thanks Olek. The slice is good, and the additional test is good. > > Now after loading the slice and running all system tests from World > > TestRunner > I get 21 errors, since they have code like this... > self assert: (Smalltalk globals classNamed: originalName) isNil. > which needs to be updated and checked that there is no clash in usage. > > Anyone know of a method like... > self assert: (Smalltalk globals classNamed: originalName) raised: > ClassNotFound. > which seems more useful than each time doing... > | correctErrorRaised | > correctErrorRaised := false. > [ Smalltalk globals classNamed: #notExistedClass ] > on: ClassNotFound do: [correctErrorRaised := true]. > self assert: correctErrorRaised. > > > btw, one of the failures is ClassTest>>testMethodsReferencingClass > but I'm a little confused by... > self assert: (ClassTest methodsReferencingClass: (Smalltalk > classNamed: #BehaviorTests)) isEmpty > > since there is no "BehaviorTests" in the Image, which effectively is... > self assert: (ClassTest methodsReferencingClass: nil) isEmpty > So is this succeeding by accident? @Pavel, @Vicent can you advise? > i guess it should be BehaviorTest not BehaviorTests, which goes to > show the value > of #classNamed: raising ClassNotFound instead of returning nil. > Definitely bug. Case 20039. > > cheers -ben > >

May 10, 2017

Re: [Pharo-dev] Adding class side inst.var to a class using Trait results in nil message sent

by Tudor Girba

Thanks, Martin. Doru > On May 10, 2017, at 5:24 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > > Ok... I reproduced it. It happens when the class uses a trait (via Metaclass>>uses:instanceVariableNames:) but no problem when no trait is used. I'll see what to do. > > Martin > > On Tue, May 9, 2017 at 4:22 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Aliaksei > thanks for the report. Now if you do not say in the title that this looks like an Epicea problem > then Martin may not see it. > Can you open a bug entry? > Stef > > On Mon, May 8, 2017 at 10:57 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > Screenshot tells everything :) > I was trying to add "asdasd" inst var > > <Screen Shot 2017-05-08 at 22.55.31.png> > > Cheers, > Alex > > -- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."

May 10, 2017

Re: [Pharo-dev] Adding class side inst.var to a class using Trait results in nil message sent

by Martin Dias

Ok... I reproduced it. It happens when the class uses a trait (via Metaclass>>uses:instanceVariableNames:) but no problem when no trait is used. I'll see what to do. Martin On Tue, May 9, 2017 at 4:22 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Aliaksei > thanks for the report. Now if you do not say in the title that this looks > like an Epicea problem > then Martin may not see it. > Can you open a bug entry? > Stef > > On Mon, May 8, 2017 at 10:57 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> Hi, >> >> Screenshot tells everything :) >> I was trying to add "asdasd" inst var >> >> [image: Inline images 1] >> >> Cheers, >> Alex >> > >

May 10, 2017

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Eliot Miranda

Hi Denis, On Tue, May 9, 2017 at 2:47 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-05-09 22:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> I get that. But there's lots of code out there that expects classNamed: >> to answer nil for names tat don't name a class. Why break all that code? >> If you had added checkedClassNamed: or some thing else then that old code >> wouldn't be broken. There needs to be some cheap way of checking whether a >> class with a specific name actually exists. classNamed: fulfilled that >> need. By redefining it you'e meant that that has to be reimplemented. >> It's not a good idea to redefine co=re behavior in this way. It breaks >> lots of code (including VMMaker). > > > You know Pharo is going own way. We want improve bad things. That's why > #name will be removed from Object in next Pharo version. That's why Pragma > #selector is deprecated. It is hard to do but we want move. > In case of #classNamed: users should be fixed. > OK, So what's the right way to see if a class exists or not without raising an error? > Maybe other people have different opinion? > _,,,^..^,,,_ best, Eliot

May 10, 2017

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Eliot Miranda

Hi Denis, On Tue, May 9, 2017 at 2:47 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-05-09 22:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> I get that. But there's lots of code out there that expects classNamed: >> to answer nil for names tat don't name a class. Why break all that code? >> If you had added checkedClassNamed: or some thing else then that old code >> wouldn't be broken. There needs to be some cheap way of checking whether a >> class with a specific name actually exists. classNamed: fulfilled that >> need. By redefining it you'e meant that that has to be reimplemented. >> It's not a good idea to redefine co=re behavior in this way. It breaks >> lots of code (including VMMaker). > > > You know Pharo is going own way. We want improve bad things. That's why > #name will be removed from Object in next Pharo version. That's why Pragma > #selector is deprecated. It is hard to do but we want move. > In case of #classNamed: users should be fixed. Maybe other people have > different opinion? > OK. Sio w -- _,,,^..^,,,_ best, Eliot

May 10, 2017

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Oleks

I rewrote that test to self should: [Smalltalk globals classNamed: #notExistedClass] raise: ClassNotFound. It looks much better now. But I can't push it because Smalltalkhub is down. Should I fix these 21 errors (rewrite the tests for example) or did you decide that we don't need ClassNotFound? I'm not an expert in this, but what will happen if some user packages already use 'isNil' to check if a class exists? Oleks -- View this message in context: http://forum.world.st/Re-08-05-17-Tabular-Data-Structures-for-Data-Analysis… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 9, 2017

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Denis Kudriashov

2017-05-09 22:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > I get that. But there's lots of code out there that expects classNamed: > to answer nil for names tat don't name a class. Why break all that code? > If you had added checkedClassNamed: or some thing else then that old code > wouldn't be broken. There needs to be some cheap way of checking whether a > class with a specific name actually exists. classNamed: fulfilled that > need. By redefining it you'e meant that that has to be reimplemented. > It's not a good idea to redefine co=re behavior in this way. It breaks > lots of code (including VMMaker). You know Pharo is going own way. We want improve bad things. That's why #name will be removed from Object in next Pharo version. That's why Pragma #selector is deprecated. It is hard to do but we want move. In case of #classNamed: users should be fixed. Maybe other people have different opinion?

May 9, 2017

GSoC 2017 Introduction

by Myroslava Romaniuk

Hello everyone I have been accepted as a GSoC student and my project is Advancing in Pharo Quality Support. Here <https://docs.google.com/document/d/1cX7VJ2QZejq_Cu6Ur28UCiUwzSD-Bu8GgSDqECi…>'s the link to my proposal, if you have any suggestions feel free to comment or send me an email, I would really appreciate some feedback. Here are also links to my github <https://github.com/myroslavarm> and linkedin <https://www.linkedin.com/in/myroslavarm/>. In short, my project consists of several subprojects: - updating rules (improving hints, moving the rules to corresponding packages) - advanced rule toggle (a functionality to enable/disable rules from Pharo settings, a shortcut to ban a rule globally) - smart error handling (display errors that occured during critique computation along the actual critiques) - match-rewrite tool (combines features of matchtool and rewritetool, improves the process of inspecting, creating, editing and removing rules) - pre-commit quality feedback (an extension to either monticello or iceberg that will show modified parts of a project and critiques related to them --- if I have time) - making rules more maintainable while reporting encountered bugs Thanks very much for this amazing opportunity to be working with all of you, and for the help you're providing us, GSoC students, with - on Discord and in the mailing list. Looking forward to the amazing summer with the Pharo community! -- Myroslava

May 9, 2017

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Eliot Miranda

Hi Denis, On Tue, May 9, 2017 at 12:51 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Eliot. > > 2017-05-09 21:27 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hmmm, classNamed: has always answered nil for nonexistent classes. Did >> this get changed? Not sure that's right. Why not add checkedClassNamed: >> or some such? > > > I created this issue. I am sure that returning nil from methods is always > bad design and many books describe it. > Also it is not consistent to #at: method: > > Smalltalk globals at: #AbsentClass. "=> raise error" > Smalltalk globals classNamed: #AbsentClass "=> nil" > > I get that. But there's lots of code out there that expects classNamed: to answer nil for names tat don't name a class. Why break all that code? If you had added checkedClassNamed: or some thing else then that old code wouldn't be broken. There needs to be some cheap way of checking whether a class with a specific name actually exists. classNamed: fulfilled that need. By redefining it you'e meant that that has to be reimplemented. It's not a good idea to redefine co=re behavior in this way. It breaks lots of code (including VMMaker). -- _,,,^..^,,,_ best, Eliot

May 9, 2017

Re: [Pharo-dev] 08/05/17 - Tabular Data Structures for Data Analysis - Oleksandr Zaytsev

by Denis Kudriashov

Hi Eliot. 2017-05-09 21:27 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hmmm, classNamed: has always answered nil for nonexistent classes. Did > this get changed? Not sure that's right. Why not add checkedClassNamed: > or some such? I created this issue. I am sure that returning nil from methods is always bad design and many books describe it. Also it is not consistent to #at: method: Smalltalk globals at: #AbsentClass. "=> raise error" Smalltalk globals classNamed: #AbsentClass "=> nil"

May 9, 2017