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

Re: [Pharo-dev] Beyond RPackages: RPackageTag and DynamicGroup

by Sergio Fedi

Thanks for the feedback. (Thanks Nicolai for confirming that) I understand all of the arguments. Somethings to spur things up: An argument in favor of having both classes handle comments is that from a user perspective: DynamicGroup - It's good to know the criteria under which classes are grouped (sometimes it's not evident, and sometimes the details are important) (Personally I have no idea of Work criteria to list classes, and have no idea of the details of the other two) RPackageTag - Although we can fall back to the package comment, the Tag is there for something. There is a communicational intention for the Tag been there. In the case of "Tests", it's quite clear. But sometimes, not so much. Having said all of these, I'm inclined to follow this path: 1 - Make the wrappers send/not send #comment to its wrapee. 2 - Let all hell break loose and force the wrapping bug to be fixed 3 - Leave for future work to add comments to DynamicGroups and Tags Note: I said "I" because Kasper may differ on this and I didn't want to put words in his mouth

May 28, 2015

Re: [Pharo-dev] HudsonBuildTools repository?

by Esteban Lorenzano

HI, Hudson tools are obsolete sinceâ¦ well, since before hudson was renamed as jenkins :) I donât know why you maintain them or what changes you did, but is not needed and we are not using them since years (I donât even remember last time I checked at them). Instead, we use zeroconf and command line (check at our configurations in ci.pharo.org <http://ci.pharo.org/> and pharo-contribution to have an ideaâ¦ Now, what we still use is the scripts to build distributions (formerly one-click, now platform dependent). You can check them at: https://github.com/pharo-project/pharo-ci <https://github.com/pharo-project/pharo-ci> Esteban > On 28 May 2015, at 10:49, Johan Brichau <johan(a)inceptive.be> wrote: > > Hi all, > > Over the past few years we have maintained our own fork of Lukasâ HudsonBuildTools package, but I noticed there are updates flowing in with newer version of Pharo. > > So, I would like to merge our version with Pharoâs (and vice-versa) but I am unable to find where the main repository for this package is. > > Can anyone point me to that? > > thanks > Johan

May 28, 2015

Re: [Pharo-dev] LinkedIn presence

by Sergio Fedi

Thank you Yuri!â

May 28, 2015

HudsonBuildTools repository?

by Johan Brichau

Hi all, Over the past few years we have maintained our own fork of Lukasâ HudsonBuildTools package, but I noticed there are updates flowing in with newer version of Pharo. So, I would like to merge our version with Pharoâs (and vice-versa) but I am unable to find where the main repository for this package is. Can anyone point me to that? thanks Johan

May 28, 2015

Re: [Pharo-dev] [Pharo-bugtracker] OrderPreservingDictionary does not properly convert to json anymore

by Sven Van Caekenberghe

Hi Paul, There are several issues here. NeoJSON cannot know that OrderPreservingDictionary is in fact a Dictionary, since it inherits from Collection. For that to work you have to add copy over the method neoJsonOn: neoJSONWriter neoJSONWriter writeMap: self This will work for encoding, but when decoding you will get back normal Dictionaries (or the #mapClass that you set on your reader). JSON does not encode types. Also, there are various implementations of ordered Dictionary out there in the wild. From Pharo 4 we have OrderedDictionary. NeoJSON cannot support them all, hence it supports none ;-) STON does solve this problem. Sven > On 28 May 2015, at 09:55, Paul Wilke <wilke(a)itsys24.de> wrote: > > Hi, > there is a bug when converting OrderPreservingDictionary's into a json > string. > > NeoJSONWriter toString: (OrderPreservingDictionary new > at: 'key' put: 'value'; > yourself). > -->["value"] > > In Pharo 2 the answer was as expected: {"key":"value"} > > > > -- > View this message in context: http://forum.world.st/OrderPreservingDictionary-does-not-properly-convert-t… > Sent from the Pharo Issue Tracker mailing list archive at Nabble.com. > _______________________________________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

May 28, 2015

[pharo-project/pharo-core] e19fa7: 50070

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e19fa76f110ca08beb2a22cd7e6454caf35839bf https://github.com/pharo-project/pharo-core/commit/e19fa76f110ca08beb2a22cd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-28 (Thu, 28 May 2015) Changed paths: A AST-Core.package/RBVariableNode.class/instance/testing/hasIncompleteIdentifier.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/class/error messages/cannotRemoveTopLevelClassErrorMesssage.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/environmentWithReferencesTo_.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/environmentWithUsersOf_.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditionHasNoReferences_.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditionHasNoSubclasses_.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditionHasNoUsers_.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditionIsNotMetaclass_.st M Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditions.st R Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/failure tests/testBadName.st A Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/failure tests/testRemoveClassWithBadNameRaisesRBRefactoringError.st A Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/failure tests/testRemoveClassWithReferencesRaisesRBRefactoringError.st R Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/failure tests/testRemoveReferenced.st A Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/private/resumeOnCannotRemoveTopLevelClassError_.st A Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRaisesRBRefactoringErrorWhenRemovingClassWithSubclasses.st M Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRemoveClass.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50069.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50070.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50069.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50070.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHRBTextStyler.class/instance/private/resolveStyleFor_.st R Shout.package/SHRBTextStyler.class/instance/visiting rb nodes/visitClassReferenceNode_.st M Shout.package/SHRBTextStyler.class/instance/visiting rb nodes/visitVariableNode_.st M System-Caching.package/TTLCache.class/instance/removing/removeStaleValues.st Log Message: ----------- 50070 15575 AST syntax highlight: clean up variable resolving a bit https://pharo.fogbugz.com/f/cases/15575 15614 TTLCache>>#removeStaleValues should use the proper #isStale: test https://pharo.fogbugz.com/f/cases/15614 15076 RBRemoveClassRefactoring slightly broken https://pharo.fogbugz.com/f/cases/15076 http://files.pharo.org/image/50/50070.zip

May 28, 2015

[pharo-project/pharo-core]

by GitHub

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

May 28, 2015

Re: [Pharo-dev] Beyond RPackages: RPackageTag and DynamicGroup

by Esteban Lorenzano

> On 28 May 2015, at 09:02, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi Sergio, > > 2015-05-28 1:56 GMT+02:00 Sergio Fedi <sergio.fedi(a)gmail.com <mailto:sergio.fedi@gmail.com>>: > Hi list! > > As we are adding comments to Packages in Pharo, we stumbled upon the fact that there are other creatures present in the package list. > > These are: > > RPackageTag, which models the tags under the package > DynamicGroup, which model the dynamic categories of LastModifiedClasses, MostViewedClasses and Work > > Objects of these classes WILL have to understand the accessor #comment > > 1 - How do we want RPackageTag and DynamicGroup to handle #comment and #comment: ? > > RPackageTags knows about the package they are in, they could answer > > self package comment > > I have no objections to add comments to the Groups. I do :) Groups are Nautilus exclusive structures, not part of the system. Why would you want to add comments there? As Stef said, in that case I, to make groups polymorphic, I would just answer an empty string. > > > 2 - Are there any other classes present in that list we are not aware of? > > No. > > > Some options we can consider: > > a - Hardcode in an generic answer to #comment, do nothing on #comment, leave them be for now > b - Have the object behave as a RPackage, it can have a persistent comment. In this case, where do we save that data? > > Since the Package Comments case is taking so long, and to keep the scope of the case in check, we are incline to handle both classes with option a. > > Another way: > The elements in the package/group list can be wrapped by an PackageTreeSelection. We can make the distinction at this > level. > PackageTreeTagSelection -> delegate to package > PackageTreePackageSelection -> set/get package comment > PackageTreeGroupSelection -> ignore > > But be aware, not all operations in Nautilus initialize the current selection correctly. > Sometimes the selected package item is a PackageTreeSelection, sometimes it is just the RPackage/-Tag/Group item. > This is a bug not yet resolved. > > > > But we wanted to check with the list first, just in case. > > Ok, now let's hear you feedback. > >

May 28, 2015

Re: [Pharo-dev] Beyond RPackages: RPackageTag and DynamicGroup

by Nicolai Hess

Hi Sergio, 2015-05-28 1:56 GMT+02:00 Sergio Fedi <sergio.fedi(a)gmail.com>: > Hi list! > > As we are adding comments to Packages in Pharo, we stumbled upon the fact > that there are other creatures present in the package list. > > These are: > > RPackageTag, which models the tags under the package > DynamicGroup, which model the dynamic categories of LastModifiedClasses, > MostViewedClasses and Work > > Objects of these classes WILL have to understand the accessor #comment > > 1 - *How do we want RPackageTag and DynamicGroup to handle #comment and > #comment: ?* > RPackageTags knows about the package they are in, they could answer self package comment I have no objections to add comments to the Groups. > 2 - *Are there any other classes present in that list we are not aware > of?* > No. > > Some options we can consider: > > a - Hardcode in an generic answer to #comment, do nothing on #comment, > leave them be for now > b - Have the object behave as a RPackage, it can have a persistent > comment. In this case, where do we save that data? > > Since the Package Comments case is taking so long, and to keep the scope > of the case in check, we are incline to handle both classes with option a. > Another way: The elements in the package/group list can be wrapped by an PackageTreeSelection. We can make the distinction at this level. PackageTreeTagSelection -> delegate to package PackageTreePackageSelection -> set/get package comment PackageTreeGroupSelection -> ignore But be aware, not all operations in Nautilus initialize the current selection correctly. Sometimes the selected package item is a PackageTreeSelection, sometimes it is just the RPackage/-Tag/Group item. This is a bug not yet resolved. > > But we wanted to check with the list first, just in case. > > Ok, now let's hear you feedback. > >

May 28, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by stepharo

Le 26/5/15 18:40, Esteban A. Maringolo a Ã©crit : > Hi, > > tl;dr: Question: Which JSON library is the "recommended" one? > > > Long: > I'm modifying the PostgresV2 package to support JSON datatype but > instead of using the JSON package from PharoExtras I'm trying to use > NeoJSON. > > The problem is no JSON parser is bundled by default, so adding the > dependency to either class is arbitrary. Why declaring a dependency would be a bad idea. You use then declare it! > > > Regards! > > Esteban A. Maringolo > >

May 28, 2015