- Pharo-dev - lists.pharo.org

[ Pharo 70 ] Build 48 PR 72 Remove-empty-protocols-on-categorize-all-uncategorized

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/18864/Remove-empty-protocols-on-categoriz… https://github.com/pharo-project/pharo/pull/72

Aug. 20, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Holger Freyther

> On 12. Aug 2017, at 17:47, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > yes, because this HOWTO is already obsolete. See: > > https://github.com/guillep/PharoIntegrationProcess/wiki/Pharo-Development-P… Ah okay. The hidden system repository explains why the IceSavedPackage didn't point to the repository I had created/set-up but to something without a location:. thank you holger

Aug. 20, 2017

[ Pharo 70 ] Build 47 PR 202 Refactor-the-MostUsedTools-of-the-world-menu-to-cut-dependencies-and-use-priorities

by Stephane Ducasse

[ Pharo 70 ] Build 47 PR 202 Refactor-the-MostUsedTools-of-the-world-menu-to-cut-dependencies-and-use-priorities https://pharo.fogbugz.com/f/cases/20247/Refactor-the-MostUsedTools-of-the-w… https://github.com/pharo-project/pharo/pull/202

Aug. 20, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Stephane Ducasse

Thanks for all the information. In Pharo 70 Object does not understand name so it will already be a step in the right direction. I think that we should do two things. - Address simply this problem for example using setName: or setClassName: instead of name: - start to prototype for a future a solution where the reflective calls are clearly identified. Stef On Sun, Aug 20, 2017 at 11:19 AM, Luke Gorrie <luke(a)snabb.co> wrote: > On 17 August 2017 at 21:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> We should not accept such kind of behavior. >> name: should not change the name of the class. > > > I had exactly such a problem a couple of weeks ago :). > > I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in > MyClass class>>on: and so called name: on the class instead of the instance. > Hilarity ensued :). > >

Aug. 20, 2017

[ Pharo 70 ] Build 46 PR 200 Space-analysis-resurrection

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mon… https://github.com/pharo-project/pharo/pull/200

Aug. 20, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Luke Gorrie

On 17 August 2017 at 21:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We should not accept such kind of behavior. > name: should not change the name of the class. > I had exactly such a problem a couple of weeks ago :). I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in MyClass class>>on: and so called name: on the class instead of the instance. Hilarity ensued :).

Aug. 20, 2017

[ Pharo 70 ] Build 46 PR 200 Latin1TextConverter-should-know-mone-encoding-names

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mon… https://github.com/pharo-project/pharo/pull/200

Aug. 20, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Nicolas Cellier

The irony is that there is no such bug in Squeak. Class does not require such selector. But it "inherits" it in Pharo because of Trait implementation (via TClass). Why Trait itself requires #name: is another question... IMO it does not. If I replace the two local send in Trait by direct i.var. access in Squeak, then the TraitsTests-Kernel all pass... Class has #setName:, though which is used in ClassBuilder, #obsolete and ImageSegment. So the same problem exists if you replace name: by setName: but it's a bit less likely. 2017-08-19 23:19 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Stephane Ducasse-3 wrote > > any idea is welcome > > From > http://forum.world.st/Woe-unto-thee-who-assigns-to- > class-side-name-td4859734.html > : > Issue 16947: Class-side Inst Var "#name" Allowed, But Breaks System > > https://pharo.fogbugz.com/f/cases/16947/Class-side-Inst- > Var-name-Allowed-But-Breaks-System > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ > Lowering-the-pain-of-newbies-tp4961937p4962584.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 20, 2017

Re: [Pharo-dev] Github and Fogbugz integration

by Dimitris Chloupis

Not Tiobe Index, Tiobe is based more on google search with the name of the language followed with the word "programming". Which is one of the reason its critics say its not reliable. As if there is a reliable way to measure popularity. The only popularity index I am familiar with that was using mainly github was poplang, but it is no longer maintained and I do not think it was based on the github issues. Of course using Github as a measure for a language popularity is a really a bad idea because Github is mainly for open source projects which means its biased towards languages that have more active open source community. Because by very far web dev has the most active open source community Javascript comes No1. Of course in reality Javascript is nowhere near the most popular language if you take into the consideration that Java dominates business and Android software and especially mobile software is extremely active. Obviously more closed source source orientated languages like C# and C++ take a huge hit even though they dominate the Windows platform while desktop still takes at least one third of the market. In the gaming world which is still a very profitable and active part of the software industry web based language are pretty much non existent and its pretty much monopolised by C/C++/C# with Java trailing way way behind, even though Java dominates on Android ultility software neither Unity or Unreal use it, both game engines are the bread and butter of game devs. In sort the language popularity field is a huge pile of mess because its widely fluctuates depending on the area and subject matter and the criteria Poplang used to be an excellent example of this http://65.39.133.14/ But is abandoned now. On Sun, Aug 20, 2017 at 3:41 AM Tim Mackinnon <tim(a)testit.works> wrote: > I also wonder when they measure the popularity of a language/community > whether GitHub issues is a measure (I suspect it is), so it may be > advantageous to show activity particularly for a smaller community. > > Like others, I'm not a big fan of fogbugz (never understood why Joel is > considered a god), but it's ok, and it's served its purpose. I'd seriously > switching. > > I Tim > > Sent from my iPhone > > On 19 Aug 2017, at 21:40, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > On Sat, Aug 19, 2017 at 10:32 PM Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> > I see little reason not to allow both ways of reporting bugs. >> It seems that the need to create an account in FB to even view/search >> issues has been a big barrier to new(er) would-be contributors. I expect >> this difficulty would be multiplied since, in the process of reporting a >> bug on GH, they would not be able to easily determine if it had already >> been opened on FB > > > Tons of issues are reported in GH that are closed minutes as the issue > they report does not even exist. Closing an issue is just a matter of > pressing a button and you can always redirect the user to the issue in FB. > > Frankly I am no fan of FB, I find Github interface less powerful but far > simpler and better designed. What annoyed me is that fogbuz did not even > subscribed me to my own issues (issues I created) . I did not go back > because I thought people ignored me , then one day I decided to create a > new bug report and found out that people have replied almost immediately to > my old ones. Then I realised that Fogbuz did not alert me through email , > then I dig up its settings and found the way enable email alerts. Suffice > to say I was not very happy with this. > > I prefer GH also because I have already been using it with Python way > before I was introduced into Pharo, so its not just newcomer who will > prefer GH , I think the vast majority of people coming from other languages > will do too. GH is almost a monopoly at this point. > > Pretty much every one says moving to git and github will be costly , like > Stef just did. Blender made the move I think a year ago, so much noise in > the mailing list whether its really worth it moving from svn to git more > than 1 million line of code and more than a decade of commits. Later > admitted it was far easier than they expected. > > Point is that people are lazy, we are just are, and we like to keep doing > things we are familiar with because learning is hard. Problem is not > learning is far more costly. > > I have been a defender of git and github in the pharo mailing lists for > years now even though many resisted me and tried to convince me how Pharo > and git will never properly work and here we are, not regretting a second > of it and I am sure that other people who were supportive too dont either. > > But I never forced my opinion on anyone and I wont now. I am just saying , > if I have the choice between github and fogbuz, for me its github all the > way. Likewise if its iceberger vs gitup , gitup all the way. > > On the other hand , its great to live in a time having so many choices ;) > >

Aug. 20, 2017

Re: [Pharo-dev] Launcher Opening Tiny Windows

by Tim Mackinnon

It's a known problem for any image that was saved in headless mode (not just launcher) - we should find a way to resolve this. Tim Sent from my iPhone > On 20 Aug 2017, at 00:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Check out this screenshot. > <http://forum.world.st/file/n4962615/Screenshot_2017-08-19_19.png> > > The red arrow points to an open "window" of a newly created Pharo 6.0 based > image, minimized to the point of barely being visible. Clicking on it makes > a title bar somewhat more visible, the edges of which can then be dragged as > any other window. > > Anyone else seeing this? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Launcher-Opening-Tiny-Windows-tp4962615.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 20, 2017