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

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

Ok. >From what you say I get the impression that maybe all the package Manifests is modelling the hack of adding metadata to RPackage. In that case, formally, we should be testing RPackage functionality. But since the hack is so semantically large that it must be held in a package, we end up having tests in that package for testing that functionality.

May 19, 2015

Re: [Pharo-dev] Default package comment

by Sergio Fedi

> > > Things that are not code, but are relevant either before or after the > loading of a package. > > Maybe you do not need a specific part for such information because I think > (hope) most packages will not require such kind of information. > Indeed I think we don't need a separate place to put this, because it's pretty rare. > Dolphin has this problem solved in a nice way (I don't know how other > Smalltalks solve it) > > Could you describe me how Dolphin does and/or if you have some screenshots? > Sure, see below. > > So, to clear thing up, > > what are you saying? > > 2 - Make more methods for other metadata such as [...] > > you may concatenate this information into the package comment for the > display part even if not yet editable. Cristal clear. In this case, then the comment functionality we are adding should be followed with more work, adding more metadata in the Manifests (or refactoring Manifests) â Top left pane: File system tree where packages are located Down left pane: Packages in the file system location selected above Tabs: *Comment *- Whatever text you put *Classes *- Classes defined by the package *Loose method*s - Methods in classes added by the package that are not in classes defined by the package *Resources *- Objects embedded in the package (that is, serialized instances) Mainly used for window views. *Globals *- Entries in the system dictionary that are defined by the package *Scripts *- This tab has four subtabs: preinstall, postinstall, preuninstall, postuninstall These scripts where ran in the appropriate stage of installing/uninstalling the package *Prerequisites *- Depending on the classes, globals, etc, referenced by the classes and methods,etc from the package, the browser determined it's dependencies and this information would be then saved in the package itself. If the package had circular dependencies, then it wouldn't allow you to save it. The prerequisites listed you the packages which yoyr package depended on and why. That is, a list of which method referenced something outside the package. *Dependents *- As prerequisites, but shows the packages that depend on your package, and why Example of Dependents: â The second dependency is created because the method references a class: agent "Answers the IAgentCtl for the receiver's avatars" agent isNull ifTrue: [ agent := *IAgentCtlEx* new. agent connected: true ]. ^agent

May 19, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Ben Coman

On Tue, May 19, 2015 at 8:25 PM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > Supposing we do that, that we put these tests in RPackageTests, > > What tests de we put in Manifest-Tests? > Sorry, I don't have the answer for that :) cheers -ben

May 19, 2015

Re: [Pharo-dev] Default package comment

by Christophe Demarey

Le 18 mai 2015 Ã 15:17, Sergio Fedi a Ã©crit : > > > Personally, I do not fear to change the comment implementation later. > > > That's what Smalltalk is good at. > > > > +1. But the most difficult thing is not to change the implementation but all its usage. > > if people start to use a feature and you change the way to use it after, it is more difficult to update all users of the feature. > > Problem is, this feature is not used now because it doesn't exist. > > Bottom line is: > > If the future usage problem is about what to put in the default comment, It's ok for me to change it however we decide. > If the future usage problem is about what other metadata we put con the Manifest then it is irrelevant for this issue. > > > > preInstallComment > > > postInstallComment > > > > what is that? if it is Smalltalk code to run before/after the installation, it should not be in the comment but in a separated method. > > Pharo misses a package setUp and tearDown methods. > > These are comments relating to thing you have to be aware of before installing and after installing the package. > For example, a behaviour changed on some objects. This example looks strange to me. It means you put some kind of changelog (or upgrade instructions) of your package in the package comments. But you do not know from which version the user will upgrade. Will you keep all upgrade instructions? > A new option on a menu. Another package that does not "get along" with this package. > > Things that are not code, but are relevant either before or after the loading of a package. Maybe you do not need a specific part for such information because I think (hope) most packages will not require such kind of information. > > > > authorshipText > > > contactDescription > > > creationDate > > > lastUpdateDate > > > > This information is meta-information on a package and should not be lost in the package comment. > > Exactly. > > Except that when you can't put it anywhere else, it usually ends up in the comment. > (my argument is: as long as you don't have anywhere else to put certain info, it's better to have it somewhere rather than nowhere, so you could suggest that in the default comment) > > > > My initial strategy was to have comments and then model the commonalities of all package comments away to the appropiate method/variable/data > > > > I already started to work on some specific package meta-data. > > As I wrote before, for now, I store it in the PackageManifest because Monticello does not have a good support for meta-data. > > But anyway, we could just see that as an "implementation details". > > What I think is important is not to work directly with the PackageManifest but having an object manipulating it and able to answer to selectors like: > > MyPackage>>description > > MyPackage>>description: aText > > We are doing the same thing then. > > > I work on a spec widget to edit some package meta-data. > > Maybe you could do the same to be able to present other meta-data than the package comment from Nautilus. It is more work and can just come for a second version. > > I think that will be necessary for sure. > > For now, it seems really easy and straightforward to show comments in Nautilus. > It uses the same real state that class comments use. > > Other metadata, I'm not sure how it would work. > That would fall more under the province of a PackageBrowser or something like that. > Dolphin has this problem solved in a nice way (I don't know how other Smalltalks solve it) Could you describe me how Dolphin does and/or if you have some screenshots? > So, to clear thing up, > what are you saying? 2 - Make more methods for other metadata such as [...] you may concatenate this information into the package comment for the display part even if not yet editable. > > 1 - Don't mention putting other information in the default package comment > 2 - Make more methods for other metadata such as [...] > 3 - Both, 1 and 2 > 4 - Other?

May 19, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Christophe Demarey

Le 15 mai 2015 Ã 07:30, Kasper Osterbye a Ã©crit : > It is unclear if literal values in Manifest classes should be on the instance > side or on the class side. > demarey wrote in the package comments thread on May 6th: > "Data is stored in raw strings in methods (instance side) of the > Manifest." > > However, when I look in the actual manifest classes, it seems like the > manifest values (from the rule checker) are stored in the class side. > > In our work on package comments, we want to put the package comments in the > manifest classes, but we are uncertain if it should be on the instance or > class side. sorry for the late reply. Indeed data used to be stored in class side of Manifests. I changed this behavior to be able to easily inspect a Manifest through the inspector. Getting back to have them on class side is not really a problem. I must admit I don't like to have classes you never instantiate but Manifest classes are just a hack to be able to store meta-dat with Monticello.

May 19, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

Supposing we do that, that we put these tests in RPackageTests, What tests de we put in Manifest-Tests?

May 19, 2015

[pharo-project/pharo-core]

by GitHub

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

May 19, 2015

[pharo-project/pharo-core] d96c8c: 50051

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d96c8c16a4c12500b6c0fc4a801c6b81e4c1dee1 https://github.com/pharo-project/pharo-core/commit/d96c8c16a4c12500b6c0fc4a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-19 (Tue, 19 May 2015) Changed paths: A Compiler.package/BytecodeEncoder.class/class/bytecode decoding/nonExtensionBytecodeAt_in_.st A Compiler.package/BytecodeEncoder.class/instance/as yet unclassified/sizeCallPrimitive_.st M Compiler.package/EncoderForSistaV1.class/README.md M Compiler.package/EncoderForSistaV1.class/class/block closure support/numLocalTempsForBlockAt_in_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genBranchIfNotInstanceOf_distance_.st M Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genSend_numArgs_.st A Compiler.package/EncoderForSistaV1.class/instance/testing/isSpecialLiteralForPush_.st A Compiler.package/EncoderForV3.class/instance/testing/isSpecialLiteralForPush_.st M Compiler.package/EncoderForV3PlusClosures.class/class/bytecode decoding/callPrimitiveCode.st M Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/bytecodeSize_.st A Kernel.package/BlockLocalTempCounter.class/instance/instruction decoding/directedSuperSend_numArgs_.st A Kernel.package/Context.class/instance/instruction decoding/directedSuperSend_numArgs_.st M Kernel.package/InstructionClient.class/instance/instruction decoding/callPrimitive_.st A Kernel.package/InstructionClient.class/instance/instruction decoding/directedSuperSend_numArgs_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushClosureTemps_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/results/v3VMHeader_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50050.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50051.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50050.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50051.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50051 15560 New bytecode set recent issues https://pharo.fogbugz.com/f/cases/15560 http://files.pharo.org/image/50/50051.zip

May 19, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Ben Coman

On Mon, May 18, 2015 at 10:02 AM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > I want to add a test to ensure #packageManifest answers a Class. > > Since RPackage is in RPackageCore, but the #packageManifest method is in > Manifest-Core > I'm not sure whether: > > > 1. I have to make the test in RPackageTest but make the test method > from the Manifest-Core package > 2. I have to make the test in RPackageTest but make the test method > from the Manifest-Tests package > 3. Create a new class in Manifest-Tests to hold this new test (and > someupcoming tests as well) > > > > I'm not sure, but I am tending to towards... use of Manifest is an implementation detail. Its RPackage behaviour you are testing, so that is where the tests should

May 19, 2015

Re: [Pharo-dev] [Pharo-users] MongoTalk: new place on smalltalkhub

by Henrik Johansen

Hi! I made some (imho) improvements to the OID implementation, if someone with write access would find time to review/commit the attached package, I'd be grateful. The commit message: Make OID implementation more compatible with the description in http://docs.mongodb.org/manual/reference/object-id/. - Use the UNIX epoch instead of Smalltalk epoch for timestamp part, store BE so it's pseudo-sortable by time (also, you can use getTimestamp() in mongo shell and get a sensible value) - Use a per-session ID instead of localhost name for machine identification. localhost name is far from unique on some platforms (always 'localhost' on Macs), better with a unique ID per image session. - Counter initialized with a random value. As an added bonus, [OID new] bench should see a ~10% increase in performance. Cheers, Henry > On 08 Jul 2013, at 2:45 , FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > > Hi, > > I've just created a new team for MongoTalk on SmalltalkHub: > > http://www.smalltalkhub.com/#!/~MongoTalkTeam <http://www.smalltalkhub.com/#%21/%7EMongoTalkTeam> > > The old repo (http://www.smalltalkhub.com/#!/~francois/MongoTalk <http://www.smalltalkhub.com/#%21/%7Efrancois/MongoTalk>) will stay just in case some scripts rely on it but you should update to the new repo: > > http://www.smalltalkhub.com/#!/~MongoTalkTeam/mongotalk <http://www.smalltalkhub.com/#%21/%7EMongoTalkTeam/mongotalk> > > I've created a version 1.5.1 in the Metacello configuration to reflect the repo migration. > Shout at me if I missed something! > > Cheers, > Fa > > (Many thanks to Norbert for pushing the migration ;)

May 19, 2015