- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] c14c16: 60367
by GitHub Jan. 31, 2017

Jan. 31, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: c14c1611ee92e5bdac7f8adad3a1b1ab49f70386 https://github.com/pharo-project/pharo-core/commit/c14c1611ee92e5bdac7f8ada… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: A ReflectionMirrors-Primitives-Tests.package/MirrorPrimitivesTests.class/instance/tests-write barrier/testMakingObjectReadOnly.st M ReflectionMirrors-Primitives.package/MirrorPrimitives.class/class/message performing/withReceiver_tryPrimitive_withArguments_.st A ReflectionMirrors-Primitives.package/MirrorPrimitives.class/class/write barrier/isObjectReadOnly_.st A ReflectionMirrors-Primitives.package/MirrorPrimitives.class/class/write barrier/makeObject_readOnly_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60366.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60367.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60366.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60367.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R WriteBarrierTests.package/TTMirror.class/README.md R WriteBarrierTests.package/TTMirror.class/definition.st R WriteBarrierTests.package/TTMirror.class/instance/mirror-access/classOf_.st R WriteBarrierTests.package/TTMirror.class/instance/mirror-access/isReadOnlyObject_.st R WriteBarrierTests.package/TTMirror.class/instance/mirror-access/setIsReadOnlyObjectOf_to_.st R WriteBarrierTests.package/WriteBarrierTest.class/instance/guinea pigs/mirror.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - helper/testProxyObject_initialState_tuples_.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - proxy/testBasicProxyReadOnly.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - proxy/testBasicProxyWritable.st Log Message: ----------- 60367 19635 DisplayScreen has depth 1 on Linux https://pharo.fogbugz.com/f/cases/19635 19634 WriteBarrier mirror methods should be moved to MirrorPrimitives https://pharo.fogbugz.com/f/cases/19634 http://files.pharo.org/image/60/60367.zip

1 0

[pharo-project/pharo-core]
by GitHub Jan. 31, 2017

Jan. 31, 2017

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

1 0

[pharo-project/pharo-core]
by GitHub Jan. 31, 2017

Jan. 31, 2017

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

1 0

[pharo-project/pharo-core] 605aea: 60366
by GitHub Jan. 31, 2017

Jan. 31, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 605aea3271c974e38784e70c39e4ae1009be9c4d https://github.com/pharo-project/pharo-core/commit/605aea3271c974e38784e70c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M Collections-Tests.package/ArrayTest.class/instance/testing/testComplexIsSelfEvaluating.st M Collections-Tests.package/DictionaryTest.class/instance/requirements/otherDictionaryClasses.st A Collections-Tests.package/ManifestCollectionsTests.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Collections-Tests.package/SplitJoinTest.class/instance/running/testSplitStringOnRegex.st A Compression-Tests.package/ZipExtensionTests.class/README.md A Compression-Tests.package/ZipExtensionTests.class/definition.st A Compression-Tests.package/ZipExtensionTests.class/instance/tests/testZipped.st M ConfigurationOfDependencyAnalyser.package/ConfigurationOfDependencyAnalyser.class/instance/symbolic versions/stable_.st A ConfigurationOfDependencyAnalyser.package/ConfigurationOfDependencyAnalyser.class/instance/versions/version121_.st M Graphics-Display Objects.package/DisplayScreen.class/class/initialize-release/initialize.st M Graphics-Display Objects.package/DisplayScreen.class/instance/private/findAnyDisplayDepthIfNone_.st M Kernel-Tests.package/MethodContextTest.class/instance/tests/verifyJumpWithSelector_.st A Kernel.package/ModificationForbidden.class/README.md A Kernel.package/ModificationForbidden.class/class/instance creation/for_atIndex_with_.st A Kernel.package/ModificationForbidden.class/class/instance creation/for_atInstVar_with_.st A Kernel.package/ModificationForbidden.class/definition.st A Kernel.package/ModificationForbidden.class/instance/accessing/fieldIndex.st A Kernel.package/ModificationForbidden.class/instance/accessing/fieldIndex_.st A Kernel.package/ModificationForbidden.class/instance/accessing/newValue.st A Kernel.package/ModificationForbidden.class/instance/accessing/newValue_.st A Kernel.package/ModificationForbidden.class/instance/accessing/object.st A Kernel.package/ModificationForbidden.class/instance/accessing/object_.st A Kernel.package/ModificationForbidden.class/instance/accessing/retrySelector.st A Kernel.package/ModificationForbidden.class/instance/accessing/retrySelector_.st A Kernel.package/ModificationForbidden.class/instance/printing/messageText.st A Kernel.package/ModificationForbidden.class/instance/printing/printObject_on_.st A Kernel.package/ModificationForbidden.class/instance/printing/standardMessageText.st A Kernel.package/ModificationForbidden.class/instance/retrying/retryModification.st A Kernel.package/ModificationForbidden.class/instance/testing/isResumable.st R Kernel.package/NoModificationError.class/README.md R Kernel.package/NoModificationError.class/definition.st R Kernel.package/NoModificationError.class/instance/accessing/index_.st R Kernel.package/NoModificationError.class/instance/accessing/object_.st R Kernel.package/NoModificationError.class/instance/accessing/selector_.st R Kernel.package/NoModificationError.class/instance/accessing/value_.st R Kernel.package/NoModificationError.class/instance/printing/messageText.st R Kernel.package/NoModificationError.class/instance/printing/printObject_on_.st R Kernel.package/NoModificationError.class/instance/printing/standardMessageText.st R Kernel.package/NoModificationError.class/instance/retrying/retryModification.st R Kernel.package/NoModificationError.class/instance/testing/isResumable.st M Kernel.package/Object.class/instance/write barrier/attemptToAssign_withIndex_.st A Moose-Algos-Graph.package/MalGraphEdge.class/instance/accessing/printOn_.st M Moose-Algos-Graph.package/MalGraphReducer.class/instance/merging/mergeNodesInCircuit_.st M Moose-Algos-Graph.package/MalLongestPath.class/definition.st M Moose-Algos-Graph.package/MalLongestPath.class/instance/computing/computeStep.st M Moose-Algos-Graph.package/MalLongestPath.class/instance/running/run.st M Moose-Algos-Graph.package/MalLongestPath.class/instance/testing/isCompleted.st A Regex-Tests-Core.package/RxExtensionsTest.class/README.md A Regex-Tests-Core.package/RxExtensionsTest.class/definition.st A Regex-Tests-Core.package/RxExtensionsTest.class/instance/tests/testSplitJoinBoundaryCases.st A Regex-Tests-Core.package/RxExtensionsTest.class/instance/tests/testSplitStringOnRegex.st M Rubric.package/RubEditingMode.class/instance/accessing/interactive.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60365.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60366.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60365.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60366.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-DependencyAnalyser-Test.package/DAPackageTest.class/instance/tests/testDependenciesFrom.st M Tool-DependencyAnalyser-Test.package/DAPackageTest.class/instance/tests/testReferenceDependenciesFrom.st M Tool-DependencyAnalyser-UI.package/DAPackageAnalyzerTreeModel.class/instance/initialization/initializeButtons.st M Tool-DependencyAnalyser-UI.package/DAPackageDependenciesWelcome.class/class/world menu/menuCommandOn_.st M Tool-DependencyAnalyser-UI.package/DATraitDependencyNode.class/instance/accessing/icon.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/setup/expectedFailures.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateIVObject.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testRetryingInstVarModification.st Log Message: ----------- 60366 17352 DisplayScreen should have a class initialization method https://pharo.fogbugz.com/f/cases/17352 19544 Better method comment for RubEditingMode>>interactive https://pharo.fogbugz.com/f/cases/19544 19614 Better names for NoModificationError and friends https://pharo.fogbugz.com/f/cases/19614 18767 Remove external dependencies from Collection-Tests https://pharo.fogbugz.com/f/cases/18767 19325 Warning: dependency declared not detected as a dependency https://pharo.fogbugz.com/f/cases/19325 http://files.pharo.org/image/60/60366.zip

1 0

Two listener sockets on same port
by Denis Kudriashov Jan. 31, 2017

Jan. 31, 2017

Hi, I remember in past there was some reports about it. And now I was a victim of this problem which is very difficult to debug. Pharo allows to start two listener sockets on same port. You will not see any error. State of both sockets will be identical. "socket isValid, socket status" will be always correct for both instances. You can play with sockets with following code: (socket := Socket newTCP) setOption: 'TCP_NODELAY' value: 1; setOption: 'SO_SNDBUF' value: 4096; setOption: 'SO_RCVBUF' value: 4096. socket listenOn: 40424 backlogSize: 32. When many listener sockets are created. Only first will receive connections. So first server will work. But others will not with no way to know why. But more dramatical scenario is when first socket becomes collected as garbage which will destroy it. In this case You will be completely confusing why your single instance in image is not working. Such case is of course some bug in how you manage sockets. But that's the problem: It is now impossible to debug such cases. Can we fix it? Is it possible to signal error when socket is not really listen? Best regards, Denis

3 8

Form/Spec based UI's in GT inspector extensions
by Torsten Bergmann Jan. 31, 2017

Jan. 31, 2017

Hi, there are a lot of examples for GT inspector extensions in the image. I've seen #tree(s), #list(s) or #table like UI's are used. Even a #text or an "image" displaying a morph (using #form keyword sent to the given composite). It is very easy to provide extension methods to adopt the inspector to own needs and I wish people would use this more in our environment and according projects. But what I still miss is an easy way to extend the inspector with REAL FORMS (which are dialog like) to better display and manipulate attributes/ivars of an object. To give a few examples: ======================= When I inspect a color instance I would like to see (and change) the RGB values as well as the HEX representation in a form in an own tab. Similar as if I would be changing a color in a graphics program. I would like to lively manipulate the RGB values easily with sliders instead of sending messages to self in the "first" inspector code pane/tab. Or think of a Person class where you can provide an own custom inspector pane to display/change the name and first name in an edit field or select the date of birth in a datepicker together with a button to apply the new values to the object. Think of a database connection object where I can manipulate the ivar storing the connection string in an edit field but also provide a "Reconnect" in the button after I changed it. Currently we by default we have the "Raw" tab and need to manipulate the object state with expressions in the code pane. For me this is not interactive enough and Pharo has much potential to be a lively objects environment here. Long story short: ================= 1. Is there any support for such kind of dialog based UI's in the inspector tabs/composites. 2. Is there any support to use Spec based UIs to extend the GT inspector? 3. Is there support to build simple UI forms for the inspector with labels and edit fields, combo boxes, radio buttons, date fields, field set, buttons, ... like in [2]. 4. If we dont have such a beast yet I guess we should work into this direction because it would make Pharo not only a lively (for message sending) but very useful environment for direct object interaction/manipulation of states. Are there any plans/work on this already? If not what would be needed to achieve that? Maybe a GSOC project? Thanks T. [1] http://101.wacom.com/UserHelp/en/Images/Dialog_OSDSetColor.png [1] https://i.stack.imgur.com/X91VL.png

2 1

[pharo-project/pharo-core]
by GitHub Jan. 31, 2017

Jan. 31, 2017

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

1 0

[pharo-project/pharo-core] a1d73b: 60365
by GitHub Jan. 31, 2017

Jan. 31, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: a1d73b1704d27971ef636f12e05f999c6ef7eb78 https://github.com/pharo-project/pharo-core/commit/a1d73b1704d27971ef636f12… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M Deprecated60.package/extension/Collection/instance/ifEmpty_ifNotEmptyDo_.st M Kernel-Tests.package/ClassHierarchyTest.class/instance/tests/testSubclasses.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60364.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60365.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60364.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60365.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogBrowser.class/class/utilities/iconFor_.st Log Message: ----------- 60365 19624 Wrong deprecated message in ifEmpty:ifNotEmptyDo: https://pharo.fogbugz.com/f/cases/19624 19625 Catalog: loaded config should not be displayed with white icon https://pharo.fogbugz.com/f/cases/19625 19129 Deprecation: The method Object>>name called from ClassHierarchyTest>>#testSubclasses has been deprecated. https://pharo.fogbugz.com/f/cases/19129 http://files.pharo.org/image/60/60365.zip

1 0

pb with primitive #primitiveScreenDepth on Linux ?
by Christophe Demarey Jan. 31, 2017

Jan. 31, 2017

Hello, With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo). DisplayScreen actualScreenDepth "(calling the primitive screenDepth)" => 32 on OS X [OK] => 24 on Linux [KO] Also, it is not consistent with the primitive 91 DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth => true on OS X => false on Linux There are some safeguard image-side but it would be great if someone could check that vm side. Christophe.

1 0

Re: [Pharo-dev] cally changed from 3 to 5 ?
by Pepe Pepino Jan. 31, 2017

Jan. 31, 2017

Ã GP HP en full full full y Ruff Ãºltima RIP de de clash Royale El ene. 30, 2017 8:11 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> escribiÃ³: > > > 2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Hi Nicolai, >> >> I'm checking all current issues marked for Pharo 6 and testing if they >> are new or the problem already existed in Pharo 5. According to it I'm >> marking it and for most cases (but not all) I'm decreasing the priority to >> "Fix if Time". >> I understand you but look at the priorities as priorities for the >> releasing process. Of course a lot such issues should be fixed and if you >> think they must be fixed for the upcoming release, increase the priority. >> Currently the assignment of priorities is on issue reporters and they use >> different personal scales. This way we can unify that a little bit. >> >> After finishing of the marking I wanted to ask people to think again >> about priorities of the reported issues. But If we already made a release >> with some issue, it probably means it is not extremely important. >> > > I am not talking about "extremely important" issues. If it is an issue > that "must be fixed for this release", I would use the "show stopper" > priority. > Now if some uses used his time to report an issue, say one as priority > "fix if time" and another one "must fix", now we put all this issues to > "fix if time", don't you think we loose some valuable information ? > If this issues won't be fixed in this release (because we don't have > enough man power) we can always put them on "Later" instead of "Pharo 6.0" > For me, it makes a difference if some issues occure in some situations, > where we can maybe work around, and can be fixed "if time" or if an issues > is a bug > that must be fixed just because the functionality is just not working > anymore. > > >> >> This step needs to be done anyway or we will never finish the release. To >> do it now gives us more time to focus on really important things. We want >> every new release to be better that release before so it makes sense to >> firstly look at new problems we created. >> > > I don't get this point. Some issues were just introduced in the pharo 5.0. > So instead of seeing this issues as "must fix", we decrease the priority as > "fix if time", so we can focus on the issues we introduced in Pharo 6.0? > > > >> Cheers, >> -- Pavel >> >> >> 2017-01-30 14:07 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> For example: >>> 19457 >>> <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-…> >>> Scrolling Versionner configuration list is very slow >>> 18778 >>> <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> >>> FileList "View as" does not work >>> 19221 >>> <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search…> >>> Rub Find And Replace can not search for "?" >>> >>> For me, these are issues that "must fix" and not "Fix If Time". Most >>> issues are only >>> fixed "if someone has the time to do it" regardless how serious they are. >>> Fixed if time looks like , we can live without this as we did since the >>> last >>> release, but actually we are just used to accept some bugs and >>> regressions because >>> we know we are to small or to few develoeper to actually fix this issues. >>> I don't see any value in downgrading the priority - else we could just >>> discard any priority. >>> >>> >>> nicolai >>> >> >> >

1 0