- Pharo-dev - lists.pharo.org

WhatsUp from: 2015-08-17 until: 2015-08-31

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-08-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Thierry Goubier

Le 16/08/2015 22:48, Dimitris Chloupis a Ã©crit : > One of the things that annoy me is how many Configurations and Baselines > pollute the package space that are of little interest to the user. It > would be nice to group them and filter them out of Nautilus unless user > asks for them. This is what AltBrowser does. All configurations are in a category named 'Configurations' and all Baselines are in a category named 'Baselines'. Unless you really search for it, you won't see it. > I really like this new approach great work. It certainly help. I have played a bit with extracting info from Configurations to classify automagically, but it doesn't work very well. Thierry > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : > > stepharo wrote > >> you get a project (group) with all your packages together ready > to work ;) > > Cool! I feel more and more that the standard "Package" pane is > only useful > > for... packaging, and when one takes off the dependency > management hat and > > puts the user hat on (i.e. most of the time), what you really > want there is > > a logical view of the system. So I see three use cases: > > - Logical view of the system - I guess this was the original > intention of > > Categories, but has been hijacked by Monticello > > - By project - which, as you just showed, we have now, yay! > > - By package - the least useful, but primary (up til now), view > > Indeed. > We will see what we get at the end but may be something like > > MyProject > AnotherProject > System > LowLevel > > And people will not be overwhelmed by hundreds of nice packages. :) > > I think that touching package contents under the assumption that the > package list is too long in the UI > is the wrong way to look at the problem. > Packages are unit of deployment and we need Projects - unit of > knowledge. And the UI should shows both > depending on the view we want to get. > > Stef > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > >

Aug. 16, 2015

Komiiter is a piece of crap

by stepharo

Hi guys, We should really seriously revisit Komitter (logic). This is **several** times that saving with it freezes my image and I cannot get it back. I'm forced to kill it from the OS part. This is not acceptable. I prefer no tool that a tool that forces me to recover my work by hand or lose it. I'm sorry but I think that it was developed too fast and we should also remove all the forks and other bad smells from it. Frankly I would remove it from Pharo50 or fix it. Stef

Aug. 16, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by stepharo

First it could be worse :) We cannot build a full ecosystem without capturing dependencies. Second we are (christophe) working since a year on the Cargo Package Manager. [Christophe knows many package manager (Java ruby and others).] With Cargo every single package expresses its dependencies instead of using external packages such as a Configuration. So we will see how it goes. Stef > One of the things that annoy me is how many Configurations and > Baselines pollute the package space that are of little interest to the > user. It would be nice to group them and filter them out of Nautilus > unless user asks for them. > > I really like this new approach great work. > > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : > > stepharo wrote > >> you get a project (group) with all your packages together ready > to work ;) > > Cool! I feel more and more that the standard "Package" pane is > only useful > > for... packaging, and when one takes off the dependency > management hat and > > puts the user hat on (i.e. most of the time), what you really > want there is > > a logical view of the system. So I see three use cases: > > - Logical view of the system - I guess this was the original > intention of > > Categories, but has been hijacked by Monticello > > - By project - which, as you just showed, we have now, yay! > > - By package - the least useful, but primary (up til now), view > > Indeed. > We will see what we get at the end but may be something like > > MyProject > AnotherProject > System > LowLevel > > And people will not be overwhelmed by hundreds of nice packages. :) > > I think that touching package contents under the assumption that the > package list is too long in the UI > is the wrong way to look at the problem. > Packages are unit of deployment and we need Projects - unit of > knowledge. And the UI should shows both > depending on the view we want to get. > > Stef > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > >

Aug. 16, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Dimitris Chloupis

One of the things that annoy me is how many Configurations and Baselines pollute the package space that are of little interest to the user. It would be nice to group them and filter them out of Nautilus unless user asks for them. I really like this new approach great work. On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr> wrote: > > > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : > > stepharo wrote > >> you get a project (group) with all your packages together ready to work > ;) > > Cool! I feel more and more that the standard "Package" pane is only > useful > > for... packaging, and when one takes off the dependency management hat > and > > puts the user hat on (i.e. most of the time), what you really want there > is > > a logical view of the system. So I see three use cases: > > - Logical view of the system - I guess this was the original intention of > > Categories, but has been hijacked by Monticello > > - By project - which, as you just showed, we have now, yay! > > - By package - the least useful, but primary (up til now), view > > Indeed. > We will see what we get at the end but may be something like > > MyProject > AnotherProject > System > LowLevel > > And people will not be overwhelmed by hundreds of nice packages. :) > > I think that touching package contents under the assumption that the > package list is too long in the UI > is the wrong way to look at the problem. > Packages are unit of deployment and we need Projects - unit of > knowledge. And the UI should shows both > depending on the view we want to get. > > Stef > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > > >

Aug. 16, 2015

Re: [Pharo-dev] 16216 Default values in NECPreferences are not initilized right

by Merwan Ouddane

On 16/08/2015 16:26, Nicolai Hess wrote: > > > 2015-08-16 15:38 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com > <mailto:merwanouddane@gmail.com>>: > > Was the NECPreferences>>defaultPopupDelay in the post script ? > > > > No, but your class initialization uses the default popup delay, it > should work if we now just call the postcript. > (better solution would be to add the enable/smart char/..../ settings > in the class init. They were already in the class initialization before my modification. Set to false. I made a bug entry to change it like it was before. https://pharo.fogbugz.com/f/cases/16237/Values-in-the-class-init-of-NECPref… > > On 16/08/2015 14:25, Merwan Ouddane wrote: > > This is really weird, in the initialization the NEC was > disabled by default, I did not changed that .... > > And even if the default value for the pop-up to appear was > 200, in a fresh image it was at 500, coming from hell U.u > > Merwan > > On 16/08/2015 10:55, stepharo wrote: > > Thanks. Can you open a new issue? > Merwan you will have to revisit your code. > > Stef > > Le 15/8/15 22:53, Nicolai Hess a Ã©crit : > > This is not good. Somehow this disables NEC. > And resets many other NEC settings, for example > if you just enables code complation again, you still > don't have > the smart characters (-> inserting matchin "or ) or } ...) > > > > > > >

Aug. 16, 2015

[pharo-project/pharo-core] 35e462: 50238

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 35e4624ef05687ec9630be362887a30a711478ea https://github.com/pharo-project/pharo-core/commit/35e4624ef05687ec9630be36… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-16 (Sun, 16 Aug 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50237.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50238.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50237.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50238.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50238 16229 NEC is disabled and prior default values are unset https://pharo.fogbugz.com/f/cases/16229 http://files.pharo.org/image/50/50238.zip

Aug. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 16, 2015

Re: [Pharo-dev] Mongo - find object by id

by stepharo

> Hi Stephane, > > I have collected my points to add to the book. > > Can you give me an entry point how to do a pull request on the paper > please? > Pillar? Editor? Script? Sounds complicated for the first time. > If you can use pillar this is better, else we will do a pass and convert it to pillar Since the chapter is for the book that should be out I'm not that editing it directly is a good. Now what we can do is to work on on a separate file that Johan or Esteban can merge to the chapter once it is finished. What I was thinking about is to have a series of extras section with for example some of the problems and solutions you encountered. How to handle loop within your domain? How to find an object by id? ... The original file is here: https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Voya… I created a VoyageAdditionalText.pier that you can edit. And this is easy - you can go to the page - fork the folder - edit in the web the file and send a pull request. if this is not working, we will add you to the project and you can directly edit this file. > Regards > Sabine > > > > 2015-08-13 16:17 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > >> Hi Stephane, >> >> sure, I am happy to give something back to the community. I dont >> have so much time because of my baby but I will try my best. >> >> Where shall I put it in? > > You can do pull requests in the paper. This way they will be close > to the original version. > > >> Sabina >> >> you know what I would really love from you .... >> this is that you reread the Voyage chapter and make a list of >> the problems you faced and that are not described in the chapter. >> You can write it in any bad ways and we can do a edit phase >> after, >> >> Why do I ask that? Because I'm stupid in Mongo and I would >> love to have a good doc. >> And only the people facing the problems can spot them nicely. >> I often write doc on things that I do not know but this is >> not working well because I'm slow in that case and .... I >> could be much better >> doing something else where I'm good at. >> >> Stef >> >> Le 12/8/15 09:40, Sabine Manaa a Ã©crit : >> >> Hi, >> >> on mongo console, this brings me a persons information >> from mongo db >> db.Persons.find({"_id" : >> ObjectId("75b900000000000000000000")}) >> >> I try to query the same person from pharo and I do not >> succeed. >> >> This makes my image hanging: >> RKAPerson selectMany: {('_id' -> (OID >> value:'75b900000000000000000000'))} >> >> also other variations e.g. >> RKAPerson selectMany: {('_id' -> >> ('75b900000000000000000000')). } >> asDictionary. >> >> do not work >> >> Other queries like >> RKAPerson selectMany:{('lastName' -> ('Maier')).} >> asDictionary. >> or >> RKAPerson selectMany:{('nextTripNumber' -> (57)).} >> asDictionary. >> >> work fine. >> >> How can I query for an object with the object id? >> >> Regards >> Sabine >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Mongo-find-object-by-id-tp4842231.html >> Sent from the Pharo Smalltalk Developers mailing list >> archive at Nabble.com. >> >> >> >> > >

Aug. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 16, 2015