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

[pharo-project/pharo-core] 054b2e: 50035

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 054b2e2582f5791735d8fbd3759b123cbfc6b608 https://github.com/pharo-project/pharo-core/commit/054b2e2582f5791735d8fbd3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-06 (Wed, 06 May 2015) Changed paths: R Collections-Streams.package/MultiByteBinaryOrTextStream.class/instance/properties-setting/setFileTypeToObject.st R Collections-Streams.package/RWBinaryOrTextStream.class/instance/properties-setting/setFileTypeToObject.st M Compression.package/extension/StandardFileStream/instance/compressFile.st R FileSystem-Core.package/AbstractFileReference.class/instance/delegated/macTypeAndCreator.st R FileSystem-Core.package/FileReference.class/instance/accessing/macTypeAndCreator.st R FileSystem-Core.package/FileReference.class/instance/accessing/setMacType_creator_.st M Graphics-Fonts.package/FontSet.class/class/filein%2Fout/fileOut.st M Monticello.package/MCDataStream.class/class/instance creation/fileNamed_.st M Monticello.package/MCDataStream.class/class/instance creation/newFileNamed_.st M Monticello.package/MCDataStream.class/class/instance creation/readOnlyFileNamed_.st A Network-Kernel.package/InternetConfiguration.class/class/HTTP Proxy/configureHttpProxy.st A Network-Kernel.package/InternetConfiguration.class/class/HTTP Proxy/setHttpProxy.st M Network-Kernel.package/InternetConfiguration.class/class/system startup/startUp.st A Network-Kernel.package/extension/MacOSPlatform/instance/configureHttpProxy.st A Network-Kernel.package/extension/OSPlatform/instance/configureHttpProxy.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script643.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script644.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50034.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50035.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Support.package/SmalltalkImage.class/instance/miscellaneous/setMacFileInfoOn_.st M System-Support.package/SmalltalkImage.class/instance/saving/saveChangesInFileNamed_.st Log Message: ----------- 50035 15119 Beautify HTTP Proxy Configuration https://pharo.fogbugz.com/f/cases/15119 15483 Clean setFileTypeToObject https://pharo.fogbugz.com/f/cases/15483 http://files.pharo.org/image/50/50035.zip

May 6, 2015

Re: [Pharo-dev] Package comments

by Marcus Denker

> On 05 May 2015, at 17:14, Kasper Osterbye <kasper(a)itu.dk> wrote: > > Marcus Denker-4 wrote >> Right now we do not have yet Package comments. >> >> But we should! >> >> MBInfo seems to be a private class of Versionnerâ¦ >> >> For package comments we first need to evaluate the design spaceâ¦ >> e.g. where to store it in the image, how to store it in Monticelloâ¦ > > OK - Makes sense. > > From my perspective, the key to getting this of the ground is to make sure > such comments can be written and read in Nautilus. The package objects used > in Nautilus are from "RPackage". > Thus, the problem, in my view reduces to: > a) How to make room in RPackage for a comment field (add one more IV) > b) How to integrate the storage of this field in connection with Monticello > as Marcus writes. > > Re b) It does seem that there several tools whihc make use of RPackage, > Monicello is not one of them. > There is a test suite RPackageMCSynchronisationTest (and subclasses) which > deal with synchronizing RPackages and Monticello. > But there is a one-to-one mapping between MCPackage and RPackageâ¦ we need to take care to keep Monticello compatible. (Else it would be so nice if MC would share the model with everyone else.. it models, yet again, classe, methods, packagesâ¦) > In the MCMczWriter there is a method serializePackage: which should be able > to store the comment, and similarly, loadpackage should be able to redo it. > In essence extending the "package" member of a mcz file (a json structure) > with an extra dictionary element. > > In addition, the RPackage<->MCPackage sync need to be extended to cover this > extra field. > Yes. Due to backward compatibility, we need to make sure to not save it in the MC model itself but as an additional entity in the zip file, that then other smalltalk can ignore. Marcus

May 6, 2015

[pharo-project/pharo-core] 83b5ff: 50034

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 83b5ff9889e54d0928b5e7cf6d6b8adc13734ded https://github.com/pharo-project/pharo-core/commit/83b5ff9889e54d0928b5e7cf… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-06 (Wed, 06 May 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1214_.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/README.md R Refactoring-Critics.package/RBIfTrueBlocksRule.class/class/accessing/uniqueIdentifierName.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/definition.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/instance/accessing/category.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/instance/accessing/group.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/instance/accessing/name.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/instance/accessing/rationale.st R Refactoring-Critics.package/RBIfTrueBlocksRule.class/instance/initialization/initialize.st R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testIfTrueBlocks.st R Rubric.package/RubEditingMode.class/class/accessing/currentUser.st R Rubric.package/RubEditingMode.class/class/accessing/userManager.st M Rubric.package/RubPlainTextMode.class/class/menu/menuOn_.st M Rubric.package/RubSmalltalkCodeMode.class/class/menu/menuOn_.st M Rubric.package/RubSmalltalkEditor.class/instance/do-its/doIt.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/browseIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/debugIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/doIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/exploreIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/implementorsOfIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/inspectIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/methodNamesContainingIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/methodStringsContainingIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/pasteInitials_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/referencesToIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/save_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/sendersOfIt_.st M Rubric.package/RubSmalltalkEditor.class/instance/editing keys/spawnIt_.st R Rubric.package/RubTextEditor.class/class/accessing/currentUser.st R Rubric.package/RubTextEditor.class/class/accessing/userManager.st R Rubric.package/RubTextEditor.class/instance/accessing/currentUser.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script642.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script643.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50033.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50034.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50034 15461 remove RBIfTrueBlocksRule https://pharo.fogbugz.com/f/cases/15461 15487 Update Rubric to version 1.2.14 https://pharo.fogbugz.com/f/cases/15487 http://files.pharo.org/image/50/50034.zip

May 6, 2015

[pharo-project/pharo-core]

by GitHub

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

May 6, 2015

"missing" exports on the windows vm

by Nicolai Hess

We have a failing test case for NB NBInterpreterProxyTest>>#testStackPointer it fails because NativeBoost loadSymbol: 'stackPointerAddress' fromModule: NativeBoost VMModule returns nil This works for the linux vm! There are other methods that can be loaded, for example: (NativeBoost loadSymbol: 'primitiveAllObjects' fromModule: NativeBoost VMModule) -> returns an address. This stopped working for the windows pharo vm around june 2014. The source that changed is cointerp.h, the prior version had EXPORT(...) declarations around all functions in cointerp.h, the current version not. Three questions: 1. Why does this still work on linux? Does it export all functions declared in a header? 2. why was it changed? (I could not found the change in the code generator, maybe we exported all functions with pragma #api and now only those with pragma #export ? 3. do we need this function to be exported? Apart from this testcases, this method is called the on image startup, but the nil return does not harm. It seems it is not part of the main vm api (like the interpreter proxy functions callable from external modules) and I didn't see code thet depend on this. There are similiar functions for which we load the function address on startup: cStackPointerAddress and cFramePointerAddress, this seems to work, but I don't know if the expected result is different. In NBInterpreterProxy>>#initialize, we try to load all fourmethods: stackPointerAddress/framePointerAddress -> nil cStackPointerAddress / cFramePointerAddress -> not nil nicolai

May 5, 2015

Re : [Pharo-dev] Rendering morph list items in NewList

by Alain Plantec

Hello I ve the impression that it is due to the redrawing of invalid rectangles. Maybe because of a lack of efficienty of the morph list Alain De:"Yuriy Tymchuk" <yuriy.tymchuk(a)me.com> Date:mar j mai PM Ã 14:13 Objet:[Pharo-dev] Rendering morph list items in NewList Hi, when I use strings for list items of NewList - everything is fine, but if I use morphs - I get a strange artifacts if another window showers over them. Here is an example video:Â https://dl.dropboxusercontent.com/u/83145561/morphItems.mov Maybe some morph gurus have an idea whatâs wrong? For now Iâve discovered that all items render themselves with #listRenderOn:atRow:bounds:color:backgroundColor:from: Cheers! Uko

May 5, 2015

Re: [Pharo-dev] Rendering morph list items in NewList

by Nicolai Hess

2015-05-05 14:13 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > when I use strings for list items of NewList - everything is fine, but if > I use morphs - I get a strange artifacts if another window showers over > them. Here is an example video: > https://dl.dropboxusercontent.com/u/83145561/morphItems.mov > > Maybe some morph gurus have an idea whatâs wrong? For now Iâve discovered > that all items render themselves with > #listRenderOn:atRow:bounds:color:backgroundColor:from: > I can not reproduce this, how do you draw the items? Did you use NewListModel or do you use just NewList ? > > Cheers! > Uko >

May 5, 2015

Re: [Pharo-dev] Package comments

by Sergio Fedi

If you need help, or just a buddy to tag along I can work with you.â

May 5, 2015

Re: [Pharo-dev] WhatsUp from: 2015-05-04 until: 2015-05-17

by Stephan Eggermont

On 04/05/15 07:00, seaside(a)rmod.lille.inria.fr wrote: > 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: Writing Morphic documentation, using the MorphicDraw example. > ### What's next, until 2015-05-17 (*): > Expanding on MorphicDraw

May 5, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

Marcus Denker-4 wrote > Right now we do not have yet Package comments. > > But we should! > > MBInfo seems to be a private class of Versionnerâ¦ > > For package comments we first need to evaluate the design spaceâ¦ > e.g. where to store it in the image, how to store it in Monticelloâ¦ OK - Makes sense. >From my perspective, the key to getting this of the ground is to make sure such comments can be written and read in Nautilus. The package objects used in Nautilus are from "RPackage". Thus, the problem, in my view reduces to: a) How to make room in RPackage for a comment field (add one more IV) b) How to integrate the storage of this field in connection with Monticello as Marcus writes. Re b) It does seem that there several tools whihc make use of RPackage, Monicello is not one of them. There is a test suite RPackageMCSynchronisationTest (and subclasses) which deal with synchronizing RPackages and Monticello. In the MCMczWriter there is a method serializePackage: which should be able to store the comment, and similarly, loadpackage should be able to redo it. In essence extending the "package" member of a mcz file (a json structure) with an extra dictionary element. In addition, the RPackage<->MCPackage sync need to be extended to cover this extra field. I believe I will set some of my time aside to playing around with that idea unless someone tells me this is all very wrong and/or a waste of time. -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4824636.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 5, 2015