Re: [Pharo-dev] [pharo-project/pharo-core] 7f3731: 40510
Nice to know. Makes a lot of sense. On Thu, Feb 26, 2015 at 12:35 AM, Sven Van Caekenberghe s...@stfx.eu wrote: Great! On 25 Feb 2015, at 16:19, Marcus Denker marcus.den...@inria.fr wrote: Log Message: --- 40510 - Scriptloader test http://files.pharo.org/image/40/40510.zip We changed Scriptloader to rely on the fact that we have it’s history in the reporsitory. This makes a lot of data not needed. (and another problem is that the scripts are not valid in the current system, e.g. when we rename a Class). This removes around 160.000 lines of code, make the image smaller by 20% and removes some load from SmalltalkHub as the Scriptloader40 package started to be near 1MB in size. In addition, this brings us a tiny step closer to the ideal that “the build server artefact should be the release, unchanged”. All this with loosing *nothing*, as the data is save and secure in the history of the package. Marcus
Re: [Pharo-dev] Slots: weak slot
On 26 Feb 2015, at 14:02, Guillermo Polito guillermopol...@gmail.com wrote:
With Camille we spent some minutes introducing a weak slot. A weak slot with
a weak reference i.e., it is not taken into account by the garbage collector.
If an object is only referenced by weak references it will be garbage
collected.
The nice thing about this is that now we can mix transparently weak and
non-weak slots inside the same object. For example:
Object subclass: #MyWeakThingy
slots: { #weakLala = WeakSlot.
#normalInstVar }
classVariables: { }
category: ‘SlotTestGuille'
Nice!
WeakSlot linesOfCode
== “24
We also implemented with Camille the #emit* methods to make it a bit faster.
A simple benchmark in my machine shows that
We should be able to use the byte code for reading/writing the tempVector here…
and access the inner array with no message send.
(but it needs some API change in IRBuilder where we have them for now just in a
version for the tempVector).
Marcus
Re: [Pharo-dev] Issue tracker: 13 issues to review
Marcus Denker-4 wrote Of those, 13 issues are tagged for review: Down to 10: 14616 could use a unit test ;) but the fix looks good - waiting for the monkey to finish to resolve to-include... 14743 closed won't fix per issue comments - Cheers, Sean -- View this message in context: http://forum.world.st/Issue-tracker-13-issues-to-review-tp4807759p4807850.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [pharo-project/pharo-core]
On 26 Feb 2015, at 15:32, Alexandre Bergel alexandre.ber...@me.com wrote: Just wondering: is there any meaning to these emails from github? No. Maybe https://zapier.com https://zapier.com/ is a solution… they have a very good email parser. - send this mail to zapper - swallow it - the other mail, parse out the interesting stuff and send a new mail to the list. It is on my TODO, like 1000 other things. Marcus
Re: [Pharo-dev] instance variable rename is deeply broken....
Ok Let me know if you need me. I'm teaching from 6 to 9. Le 26/2/15 16:39, Marcus Denker a écrit : On 26 Feb 2015, at 16:36, stepharo steph...@free.fr wrote: Marcus I browse the changes of the previous version of the refactoring package core containing the refactoring definition and I could not find anythiong. this is strange because it was before mark left. Yes, but two things happened at once: one issue was proposing to add a flag, one issue to remove the whole mechanism. As I did not realise that it was broken, I integrated the flag, not the removal. Marcus Le 26/2/15 16:15, Marcus Denker a écrit : On 26 Feb 2015, at 16:12, stepharo steph...@free.fr wrote: This was a BAD IDEA to rename naively accessors when we rename an instance variable. Now I cannot use instance renaming because of the ripple effects I do not control. And I just got an emergency evaluator when I simply wanted to rename an instance variable in ButtonModel :( Mark do you know if your changes go integrated? His changes where integrated, the undo of this not. Yes, we should remove this... Because now I will work without refactoring and I have all the spec classes to change. Not fun. Stef
Re: [Pharo-dev] a lesson about pragma
I think that fundamentally you should not use pragmas for documentation. I guess that people use it to be able to provide minimal structure for their documentation. A better solution would be to have a simple convention for this kind of structure that is easy to parse, e.g using newlines to separate the ‘keywords’ and their ‘values’ and just have a comment. For example: Now: api: #block getter: #acceptBlock registration: #whenAcceptBlockChanged: Comment convention: “ api: #block getter: #acceptBlock registration: #whenAcceptBlockChanged: Easy to parse, and easy to write conversion logic for batch transformation of these comments. On Feb 26, 2015, at 13:12, Ben Coman b...@openinworld.com wrote: Could you provide a sample, so this anti-pattern is more clear. cheers -ben On Fri, Feb 27, 2015 at 12:08 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: We are cleaning spec and the fact that method selectors are used everywhere in pragmas as meta description makes the navigation terrible. I'm removing them to be able to understand who is really calling the methods. So there is probably a lesson there. Stef --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
[Pharo-dev] [pharo-project/pharo-core] 2c9715: 40515
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 2c97150c89a5d721e1ee3ba58da121471cace6bd https://github.com/pharo-project/pharo-core/commit/2c97150c89a5d721e1ee3ba58da121471cace6bd Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-02-26 (Thu, 26 Feb 2015) Changed paths: A NewValueHolder.package/ValueChanged.class/README.md A NewValueHolder.package/ValueChanged.class/class/instance creation/newValue_.st A NewValueHolder.package/ValueChanged.class/class/instance creation/oldValue_newValue_.st A NewValueHolder.package/ValueChanged.class/definition.st A NewValueHolder.package/ValueChanged.class/instance/accessing/newValue.st A NewValueHolder.package/ValueChanged.class/instance/accessing/newValue_.st A NewValueHolder.package/ValueChanged.class/instance/accessing/oldValue.st A NewValueHolder.package/ValueChanged.class/instance/accessing/oldValue_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script514.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script515.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40514.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40515.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/AbstractAdapter.class/instance/factory/buildWidget.st M Spec-Core.package/AbstractWidgetModel.class/instance/api-events/whenBorderColorChanged_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api-events/whenBorderWidthChanged_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api-events/whenEnabledChanged_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api-events/whenHelpChanged_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/borderColor.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/borderColor_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/borderWidth.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/borderWidth_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/disable.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/enable.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/enabled.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/enabled_.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/help.st M Spec-Core.package/AbstractWidgetModel.class/instance/api/help_.st M Spec-Core.package/ButtonModel.class/definition.st M Spec-Core.package/ButtonModel.class/instance/api-events/whenActionPerformedDo_.st M Spec-Core.package/ButtonModel.class/instance/api-events/whenLabelChangedDo_.st M Spec-Core.package/ButtonModel.class/instance/api-events/whenStateChangedDo_.st M Spec-Core.package/ButtonModel.class/instance/api/action.st M Spec-Core.package/ButtonModel.class/instance/api/action_.st M Spec-Core.package/ButtonModel.class/instance/api/getAction.st M Spec-Core.package/ButtonModel.class/instance/api/label_.st M Spec-Core.package/ButtonModel.class/instance/api/shortcut.st M Spec-Core.package/ButtonModel.class/instance/api/shortcut_.st M Spec-Core.package/ButtonModel.class/instance/api/state_.st M Spec-Core.package/ButtonModel.class/instance/initialization/initialize.st M Spec-Core.package/ButtonModel.class/instance/morphic/label.st M Spec-Core.package/ButtonModel.class/instance/morphic/state.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenActivatedDo_.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenActivationActionChanged_.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenChangedDo_.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenDesactivatedDo_.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenDesactivationActionChanged_.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenLabelChanged_.st M Spec-Core.package/CheckBoxModel.class/instance/api-events/whenLabelClickableChanged_.st M Spec-Core.package/CheckBoxModel.class/instance/api/activationAction_.st M Spec-Core.package/CheckBoxModel.class/instance/api/click.st M Spec-Core.package/CheckBoxModel.class/instance/api/desactivationAction_.st M Spec-Core.package/CheckBoxModel.class/instance/api/label.st M Spec-Core.package/CheckBoxModel.class/instance/api/labelClickable.st M Spec-Core.package/CheckBoxModel.class/instance/api/labelClickable_.st M Spec-Core.package/CheckBoxModel.class/instance/api/label_.st M Spec-Core.package/CheckBoxModel.class/instance/api/state.st M Spec-Core.package/CheckBoxModel.class/instance/api/state_.st M Spec-Core.package/CheckBoxModel.class/instance/api/toggleState.st M
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40515 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] a lesson about pragma
Could you provide a sample, so this anti-pattern is more clear. cheers -ben On Fri, Feb 27, 2015 at 12:08 AM, stepharo steph...@free.fr wrote: We are cleaning spec and the fact that method selectors are used everywhere in pragmas as meta description makes the navigation terrible. I'm removing them to be able to understand who is really calling the methods. So there is probably a lesson there. Stef
Re: [Pharo-dev] a lesson about pragma
On 26 Feb 2015, at 5:12 , Ben Coman b...@openinworld.com wrote: Could you provide a sample, so this anti-pattern is more clear. cheers -ben acceptBlock: aBlockWithOneArgument api: #block getter: #acceptBlock registration: #whenAcceptBlockChanged: Set the block to perform when the text is accepted. The block must have one argument, which will be the accepted text. The block can return false if the candidate text is to be rejected Senders of acceptBlock / whenAcceptBlockChanged now includes acceptBlock: I guess the pragma is used to autogenerate documentation in sync with the source, but then it's a bit strange that the description is in a comment rather than the pragma itself. Haven't seen a setter/getter pair that deviates from the standard yet, but one must exist for there to be a keyword reserved for it in the pragma... right? Cheers, Henry
[Pharo-dev] were the fixes of Mark integrated? Because rename instance variable looks broken
When I select an instance variable shortcut and I want to rename it using Smart Suggestions I get shortcutHolderHolder in my method. Stef
[Pharo-dev] [pharo-project/pharo-core] a5b1bb: 40514
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: a5b1bb2acb02b3580a0ad2bb2792a3468bf619da https://github.com/pharo-project/pharo-core/commit/a5b1bb2acb02b3580a0ad2bb2792a3468bf619da Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-02-26 (Thu, 26 Feb 2015) Changed paths: M AsmJit-Tests.package/AJx64AssemblerTests.class/instance/tests/testStringOps64Mnemonics.st M AsmJit-Tests.package/AJx86AssemblerTests.class/instance/tests/testStringOpMnemonics.st M AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitsmnemonic_operand1_operand2_operand3_.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/README.md A Reflectivity-Tests.package/ReflectiveMethodTest.class/definition.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - creation/testCreateReflectiveMethod.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - creation/testCreateReflectiveMethodAndInvalidate.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - creation/testInvalidate.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - creation/testInvalidateWithLinCount.st A Reflectivity-Tests.package/ReflectivityExamples.class/README.md A Reflectivity-Tests.package/ReflectivityExamples.class/definition.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/as yet unclassified/exampleMethod.st A Reflectivity.package/ReflectiveMethod.class/README.md A Reflectivity.package/ReflectiveMethod.class/class/as yet unclassified/on_.st A Reflectivity.package/ReflectiveMethod.class/definition.st A Reflectivity.package/ReflectiveMethod.class/instance/accessing/ast.st A Reflectivity.package/ReflectiveMethod.class/instance/accessing/compiledMethod_.st A Reflectivity.package/ReflectiveMethod.class/instance/accessing/linkCount.st A Reflectivity.package/ReflectiveMethod.class/instance/accessing/linkCount_.st A Reflectivity.package/ReflectiveMethod.class/instance/evaluation/recompileAST.st A Reflectivity.package/ReflectiveMethod.class/instance/evaluation/run_with_in_.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/createTwin.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/destroyTwin.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/invalidate.st A Reflectivity.package/ReflectiveMethod.class/instance/reflective operations/doesNotUnderstand_.st A Reflectivity.package/ReflectiveMethod.class/instance/testing/hasLinks.st A Reflectivity.package/extension/CompiledMethod/instance/createTwin.st A Reflectivity.package/extension/CompiledMethod/instance/destroyTwin.st A Reflectivity.package/extension/CompiledMethod/instance/invalidate.st A Reflectivity.package/extension/CompiledMethod/instance/reflectiveMethod.st A Reflectivity.package/extension/CompiledMethod/instance/reflectiveMethod_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script513.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script514.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40513.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40514.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/WeakSlot.class/README.md A Slot.package/WeakSlot.class/definition.st A Slot.package/WeakSlot.class/instance/as yet unclassified/emitStore_.st A Slot.package/WeakSlot.class/instance/as yet unclassified/emitValue_.st A Slot.package/WeakSlot.class/instance/as yet unclassified/initialize_.st A Slot.package/WeakSlot.class/instance/as yet unclassified/read_.st A Slot.package/WeakSlot.class/instance/as yet unclassified/wantsInitalization.st A Slot.package/WeakSlot.class/instance/as yet unclassified/write_to_.st Log Message: --- 40514 14999 Twin: add base for Reflectivity https://pharo.fogbugz.com/f/cases/14999 14033 Failing test: AJx64AssemblerTests#testStringOps64Mnemonics https://pharo.fogbugz.com/f/cases/14033 14998 Add WeakSlot https://pharo.fogbugz.com/f/cases/14998 http://files.pharo.org/image/40/40514.zip
Re: [Pharo-dev] OSProcess bug ?
On Thu, Feb 26, 2015 at 12:05 AM, David T. Lewis le...@mail.msen.com wrote: Hi Jannik, One other thing I just thought of: Check and see if your rostopic program is actually writing to standard output, as opposed to writing directly to /dev/tty. From a terminal window, I think you could do this: $ rostopic out.txt Would using a pipe better represent the interaction with OSProcess? e.g... $ rostopic | tail cheers -ben
Re: [Pharo-dev] were the fixes of Mark integrated? Because rename instance variable looks broken
On 26 Feb 2015, at 16:09, stepharo steph...@free.fr wrote: When I select an instance variable shortcut and I want to rename it using Smart Suggestions I get shortcutHolderHolder in my method. everything is integrated. Marcus
Re: [Pharo-dev] instance variable rename is deeply broken....
rename: aVarName to: aName in: aClass self rename: aVarName to: aName in: aClass renameAccessors: false ^ (false makes sure that there is no renaming). On 26 Feb 2015, at 16:12, stepharo steph...@free.fr wrote: This was a BAD IDEA to rename naively accessors when we rename an instance variable. Now I cannot use instance renaming because of the ripple effects I do not control. And I just got an emergency evaluator when I simply wanted to rename an instance variable in ButtonModel :( Mark do you know if your changes go integrated? His changes where integrated, the undo of this not. Yes, we should remove this... I did not get the undo. But in my image renaming a variables renames the accessors and more. To work I modified to put false instead of true. rename: aVarName to: aName in: aClass self rename: aVarName to: aName in: aClass renameAccessors: false I can prepare a slice to either remove the behavior or at least turn it off. Because now I will work without refactoring and I have all the spec classes to change. Not fun. Stef
Re: [Pharo-dev] [regression reporter]regression occurred
On 26 Feb 2015, at 15:35, Ben Coman b...@openinworld.com wrote: On Feb 25, 2015 3:58 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Number#brickValue: must die ! On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote: https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/ 1 regressions found. KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker marcus.den...@inria.fr wrote: On 25 Feb 2015, at 16:04, Aliaksei Syrel alex.sy...@gmail.com wrote: It is already fixed and will be integrated with GT When will this happen? this test fails since *WEEKS*, yet I could have fixed it in 5 minutes. But I can’t. We make ourselves completely powerless. This does not make me feel good. On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel alex.sy...@gmail.com wrote: Normally GT should be released more often. This time while Jenkins was down we did a lot of changes and now it takes some time to prepare everything for integration. Also at the moment of previous release moose didn't run tests like BehaviourTest and others. :) Thats a fair reason, but philosophically we still have a feature branch holding up a bug fix, because we have a a single-branch workflow. Consider a future where Pharo has more external packages, where a hypothetical package (with less diligent developers than GT) has a longer feature development cycle. Should bug fixes be held up? Or should external packages have a bug-fix-branch and a feature-development-branch - with a workflow where before the feature-development-branch is integrated, it merges in any bug-fix-branch commits. I think that in certain cases (something urgent, something really annoying) it would be OK to patch it directly. It is then up to the external package maintainers to pick up the change up stream. Working with components/modules should not limit what we do. Of course, for new features this would not be OK. p.s. It would be interesting if we could get a github-style commit network graph derived from mcz files. cheers -ben
[Pharo-dev] instance variable rename is deeply broken....
This was a BAD IDEA to rename naively accessors when we rename an instance variable. Now I cannot use instance renaming because of the ripple effects I do not control. And I just got an emergency evaluator when I simply wanted to rename an instance variable in ButtonModel :( Mark do you know if your changes go integrated? Because now I will work without refactoring and I have all the spec classes to change. Not fun. Stef
Re: [Pharo-dev] instance variable rename is deeply broken....
On 26 Feb 2015, at 16:36, stepharo steph...@free.fr wrote: Marcus I browse the changes of the previous version of the refactoring package core containing the refactoring definition and I could not find anythiong. this is strange because it was before mark left. Yes, but two things happened at once: one issue was proposing to add a flag, one issue to remove the whole mechanism. As I did not realise that it was broken, I integrated the flag, not the removal. Marcus Le 26/2/15 16:15, Marcus Denker a écrit : On 26 Feb 2015, at 16:12, stepharo steph...@free.fr wrote: This was a BAD IDEA to rename naively accessors when we rename an instance variable. Now I cannot use instance renaming because of the ripple effects I do not control. And I just got an emergency evaluator when I simply wanted to rename an instance variable in ButtonModel :( Mark do you know if your changes go integrated? His changes where integrated, the undo of this not. Yes, we should remove this... Because now I will work without refactoring and I have all the spec classes to change. Not fun. Stef
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40514 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] Recording user actions in GTools
Hi, In order to better understand how people use the GT tools we would like to integrate, before the Pharo code freeze, a small extension to GT tools (300 lines of code) that records and sends usage data. The recording of data will be opt-out: *you have to explicitly agree with sending usage data*. The first time you open a GT tool, that tool will embed a small UI asking you if you want to enable data submission. We will save the setting in the your preference directory so it will be shared between all your local images. You can change this setting at any time from the Settings Browser. For now we will only like to collect data about Spotter. *By default we will only collect anonymous data *about various actions you do in spotter (open, close, search, dive-in, dive-out, select element, etc) without collecting any data what about what query you enter or what search results you get. We would also add an optional setting for sending the query text and selected elements. We will send then the data periodically to our server and when you close the image. The data that will be send is rather small: 1000 actions require 7kb of data. Thus sending an entire day worth of recordings, if all you did that day was searching, should be around 1MB of data. The recording does not influence the performance of Spotter. Spotter already generates all events of interest as announcements. To enable recording we just register a subscriber with the Spotter announcer and store the events of interest. We would like to get your opinion on this. Cheers, GT team
Re: [Pharo-dev] [pharo-project/pharo-core] 7f3731: 40510
Really great! Doru On Wed, Feb 25, 2015 at 5:35 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Great! On 25 Feb 2015, at 16:19, Marcus Denker marcus.den...@inria.fr wrote: Log Message: --- 40510 - Scriptloader test http://files.pharo.org/image/40/40510.zip We changed Scriptloader to rely on the fact that we have it’s history in the reporsitory. This makes a lot of data not needed. (and another problem is that the scripts are not valid in the current system, e.g. when we rename a Class). This removes around 160.000 lines of code, make the image smaller by 20% and removes some load from SmalltalkHub as the Scriptloader40 package started to be near 1MB in size. In addition, this brings us a tiny step closer to the ideal that “the build server artefact should be the release, unchanged”. All this with loosing *nothing*, as the data is save and secure in the history of the package. Marcus -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] Slots: weak slot
With Camille we spent some minutes introducing a weak slot. A weak slot
with a weak reference i.e., it is not taken into account by the garbage
collector. If an object is only referenced by weak references it will be
garbage collected.
The nice thing about this is that now we can mix transparently weak and
non-weak slots inside the same object. For example:
Object subclass: #MyWeakThingy
slots: { #weakLala = WeakSlot.
#normalInstVar }
classVariables: { }
category: 'SlotTestGuille'
weakLala: someLala
weakLala:= someLala
weakLala
^ weakLala
weak := MyWeakThingy new.
o:= Object new.
weak weakLala. =Object new
o :=nil.
weak weakLala. =nil
We also implemented with Camille the #emit* methods to make it a bit
faster. A simple benchmark in my machine shows that
With no optimizations
[weak weakLala:o] bench 14,338,031 per second
With optimizations
[weak weakLala:o] bench 27,955,761 per second
A normal array access
someArray := Array new: 1.
[someArray at: 1 put: o] bench '39,609,322 per second'
We commited it into the inbox, the issue is the following:
https://pharo.fogbugz.com/f/cases/14998/Add-WeakSlot
Camille Guille
Re: [Pharo-dev] MCVersionInfo: 10% of the image
Excellent! Le 26/2/15 11:11, Thierry Goubier a écrit : 2015-02-26 10:51 GMT+01:00 Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com: 2015-02-26 10:44 GMT+01:00 Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr: On 26 Feb 2015, at 10:15, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Works fine with merge, too. The 511 image is 23.2MB after. This means with the Scriptloader fix from 510 together we would over 10MB… or nearly 1/3. Nice! Ok. Second scheme (get it to work everywhere, everytime) seems to just need to change MCWorkingAncestryaddAncestor: and MCWorkingCopy addStepChild: Done. Slice uploaded.Tried with loading Roassal2, then flushing the Monticello package cache: MCVersionInfo allInstances size 2 Thierry Thierry Marcus
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40512 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 0a76bd: 40512
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 0a76bdbdedb4c2aa20a2a798b8c91a51d0bc9498 https://github.com/pharo-project/pharo-core/commit/0a76bdbdedb4c2aa20a2a798b8c91a51d0bc9498 Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-02-26 (Thu, 26 Feb 2015) Changed paths: A Collections-Sequenceable.package/LinkedList.class/instance/enumerating/select_thenCollect_.st M Kernel.package/Delay.class/class/instance creation/timeoutSemaphore_afterMSecs_.st M Kernel.package/MonitorDelay.class/class/instance creation/signalLock_afterMSecs_inMonitor_queue_.st A KernelTests.package/DelayTest.class/instance/testing/testTimeoutSemaphoreAfterMSecs.st A KernelTests.package/MonitorTest.class/instance/tests/testWaitMaxMilliseconds.st A Keymapping-Tools-Spec.package/KMDescription.class/instance/api/categories_.st R Keymapping-Tools-Spec.package/KMDescription.class/instance/protocol/categories_.st A Komitter.package/CredentialEditor.class/instance/api/getPassword.st A Komitter.package/CredentialEditor.class/instance/api/getUsername.st A Komitter.package/CredentialEditor.class/instance/api/initialExtent.st A Komitter.package/CredentialEditor.class/instance/api/setPassword_.st A Komitter.package/CredentialEditor.class/instance/api/setUsername_.st A Komitter.package/CredentialEditor.class/instance/api/title.st R Komitter.package/CredentialEditor.class/instance/protocol/getPassword.st R Komitter.package/CredentialEditor.class/instance/protocol/getUsername.st R Komitter.package/CredentialEditor.class/instance/protocol/initialExtent.st R Komitter.package/CredentialEditor.class/instance/protocol/setPassword_.st R Komitter.package/CredentialEditor.class/instance/protocol/setUsername_.st R Komitter.package/CredentialEditor.class/instance/protocol/title.st A Komitter.package/KomitClassNode.class/instance/api/label.st A Komitter.package/KomitClassNode.class/instance/initialization/initialize.st R Komitter.package/KomitClassNode.class/instance/initialize/initialize.st R Komitter.package/KomitClassNode.class/instance/protocol/label.st A Komitter.package/KomitDefinitionNode.class/instance/api/label.st R Komitter.package/KomitDefinitionNode.class/instance/protocol/label.st A Komitter.package/KomitLeaf.class/instance/initialization/initialize.st R Komitter.package/KomitLeaf.class/instance/initialize/initialize.st A Komitter.package/KomitMethodNode.class/instance/api/label.st R Komitter.package/KomitMethodNode.class/instance/protocol/label.st A Komitter.package/KomitNode.class/instance/api/icon.st A Komitter.package/KomitNode.class/instance/api/ifNotSilentDo_.st A Komitter.package/KomitNode.class/instance/api/label.st A Komitter.package/KomitNode.class/instance/api/silentWhile_.st A Komitter.package/KomitNode.class/instance/initialization/initialize.st R Komitter.package/KomitNode.class/instance/initialize/initialize.st R Komitter.package/KomitNode.class/instance/protocol/icon.st R Komitter.package/KomitNode.class/instance/protocol/ifNotSilentDo_.st R Komitter.package/KomitNode.class/instance/protocol/label.st R Komitter.package/KomitNode.class/instance/protocol/silentWhile_.st A Komitter.package/KomitPackageNode.class/instance/api/icon.st A Komitter.package/KomitPackageNode.class/instance/api/label.st A Komitter.package/KomitPackageNode.class/instance/initialization/initialize.st R Komitter.package/KomitPackageNode.class/instance/initialize/initialize.st R Komitter.package/KomitPackageNode.class/instance/protocol/icon.st R Komitter.package/KomitPackageNode.class/instance/protocol/label.st A Komitter.package/KomitSliceUI.class/instance/api/initialExtent.st A Komitter.package/KomitSliceUI.class/instance/api/issueNumberText.st A Komitter.package/KomitSliceUI.class/instance/api/title.st A Komitter.package/KomitSliceUI.class/instance/api/titleText.st A Komitter.package/KomitSliceUI.class/instance/api/valid.st A Komitter.package/KomitSliceUI.class/instance/api/valid_.st R Komitter.package/KomitSliceUI.class/instance/protocol/initialExtent.st R Komitter.package/KomitSliceUI.class/instance/protocol/issueNumberText.st R Komitter.package/KomitSliceUI.class/instance/protocol/title.st R Komitter.package/KomitSliceUI.class/instance/protocol/titleText.st R Komitter.package/KomitSliceUI.class/instance/protocol/valid.st R Komitter.package/KomitSliceUI.class/instance/protocol/valid_.st A Komitter.package/KomitterUI.class/instance/api/addRoot_.st A Komitter.package/KomitterUI.class/instance/api/cancel.st A Komitter.package/KomitterUI.class/instance/api/initialExtent.st A Komitter.package/KomitterUI.class/instance/api/komit.st A Komitter.package/KomitterUI.class/instance/api/model.st A
Re: [Pharo-dev] Bug? JPEG reading ignores EXIF Orientation
We should improve the Image support because it is dated. Le 25/2/15 04:03, J.F. Rick a écrit : A lot of mobile phone cameras use the EXIF metadata of JPEG to indicate the orientation of the image (i.e., vertical vs horizontal, upside down, etc.). In Pharo 3 (I doubt it has changed in Pharo 4), that data is ignored. So, when you convert a photo taken from a mobile device to a form, it will probably be in the wrong orientation. This is true for both JPEGReadWriter and PluginBasedJPEGReadWriter. Anybody got any knowledge about this? If not, I'll add it as a bug to FogBugz. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] [regression reporter]regression occurred
On Feb 25, 2015 3:58 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Number#brickValue: must die ! On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote: https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/ 1 regressions found. KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker marcus.den...@inria.fr wrote: On 25 Feb 2015, at 16:04, Aliaksei Syrel alex.sy...@gmail.com wrote: It is already fixed and will be integrated with GT When will this happen? this test fails since *WEEKS*, yet I could have fixed it in 5 minutes. But I can’t. We make ourselves completely powerless. This does not make me feel good. On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel alex.sy...@gmail.com wrote: Normally GT should be released more often. This time while Jenkins was down we did a lot of changes and now it takes some time to prepare everything for integration. Also at the moment of previous release moose didn't run tests like BehaviourTest and others. :) Thats a fair reason, but philosophically we still have a feature branch holding up a bug fix, because we have a a single-branch workflow. Consider a future where Pharo has more external packages, where a hypothetical package (with less diligent developers than GT) has a longer feature development cycle. Should bug fixes be held up? Or should external packages have a bug-fix-branch and a feature-development-branch - with a workflow where before the feature-development-branch is integrated, it merges in any bug-fix-branch commits. p.s. It would be interesting if we could get a github-style commit network graph derived from mcz files. cheers -ben
Re: [Pharo-dev] [pharo-project/pharo-core]
Just wondering: is there any meaning to these emails from github? Cheers, Alexandre On Feb 26, 2015, at 11:29 AM, GitHub nore...@github.com wrote: Branch: refs/tags/40513 Home: https://github.com/pharo-project/pharo-core -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [pharo-project/pharo-core]
There is a git tag for each Pharo releases: https://github.com/pharo-project/pharo-core/releases On Thu, Feb 26, 2015 at 3:32 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Just wondering: is there any meaning to these emails from github? Cheers, Alexandre On Feb 26, 2015, at 11:29 AM, GitHub nore...@github.com wrote: Branch: refs/tags/40513 Home: https://github.com/pharo-project/pharo-core -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Serge Stinckwich UCBN UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Re: [Pharo-dev] MCVersionInfo: 10% of the image
Thierry this is really interesting. Could you add the logic in some class comments for the future? Stef Le 26/2/15 10:15, Thierry Goubier a écrit : Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Thierry 2015-02-26 9:33 GMT+01:00 Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr: And it behaves as the non-lazy one. There are a few things to change GUI-side to avoid an unnecessary loading of the complete ancestry of all the packages in the image, but this is workable. I see two ways of using it: as an install, flush package cache before release and gain 5MB of RAM. If you start regularly developping (loading packages, etc...) then new packages will revert to non-lazy version info (without: 'please wait, I'm loading ancestry' moments). as a permanent change in MC. The change is a bit more intrusive (need to change how working copies are created) but, well, as long as the worked on packages are inside the in-memory MC package cache, behavior is exactly the same as a non-lazy version info. As you prefer. My focus is that we ship an image that is not growing indefinitely… so this means it needs to be part of the release. I don’t care too much that the image is large when I work, but it should not come with all this data in memory when it can be calculated (or lazyly loaded) when needed. I added an issue: https://pharo.fogbugz.com/default.asp?14997 Thanks! Marcus
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40513 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 446c22: 40513
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 446c22b4124aefd20398ecb846326defe09313f1 https://github.com/pharo-project/pharo-core/commit/446c22b4124aefd20398ecb846326defe09313f1 Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-02-26 (Thu, 26 Feb 2015) Changed paths: M ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/accessing/stable_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/baselines/baseline25_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/baselines/baseline26_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/versions/version256_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/versions/version261_.st A ConfigurationOfZincHTTPComponents.package/ConfigurationOfZincHTTPComponents.class/instance/versions/version262_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script512.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script513.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40512.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40513.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/README.md A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/class/instance creation/on_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/definition.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/accessing/linesDo_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/accessing/nextLine.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/beWide.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/bufferStream_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/close.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/initialize.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/initialize/on_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/private/streamContents_.st A Zinc-Character-Encoding-Core.package/ZnFastLineReader.class/instance/testing/atEnd.st A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/README.md A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/definition.st A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/instance/testing/testLinesDo.st A Zinc-Character-Encoding-Tests.package/ZnFastLineReaderTests.class/instance/testing/testNextLine.st M Zinc-HTTP.package/ZnClient.class/instance/cleanup/close.st A Zinc-HTTP.package/ZnClient.class/instance/options/certificate.st A Zinc-HTTP.package/ZnClient.class/instance/options/certificate_.st M Zinc-HTTP.package/ZnClient.class/instance/private logging/logConnectionEstablishedTo_started_.st M Zinc-HTTP.package/ZnClient.class/instance/private/newConnectionTo_.st A Zinc-HTTP.package/ZnClient.class/instance/testing/isBadRequest.st M Zinc-HTTP.package/ZnClientLogEvent.class/instance/printing/printContentsOn_.st M Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/initialization/initialize.st M Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/responses/formTest1_.st A Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/responses/formTest2_.st A Zinc-HTTP.package/ZnDefaultServerDelegate.class/instance/responses/formTest3_.st M Zinc-HTTP.package/ZnDigestAuthenticator.class/class/accessing/md5Hash_.st M Zinc-HTTP.package/ZnEntity.class/class/instance creation/readBinaryFrom_usingType_andLength_.st A Zinc-HTTP.package/ZnEntity.class/instance/initialize-release/readBinaryFrom_.st A Zinc-HTTP.package/ZnEntityReader.class/instance/private/withDefaultUtf8Decoding_.st M Zinc-HTTP.package/ZnEntityReader.class/instance/public/readEntity.st A Zinc-HTTP.package/ZnEntityWriter.class/instance/private/withDefaultUtf8Encoding_.st M Zinc-HTTP.package/ZnEntityWriter.class/instance/public/writeEntity_.st M Zinc-HTTP.package/ZnLogEvent.class/class/convenience/logToTranscript.st M Zinc-HTTP.package/ZnMimePart.class/class/instance creation/fieldName_fileName_entity_.st A Zinc-HTTP.package/ZnMimePart.class/class/instance creation/readBinaryFrom_.st M Zinc-HTTP.package/ZnMimePart.class/instance/accessing/fileName.st A Zinc-HTTP.package/ZnMimePart.class/instance/initialize-release/readBinaryFrom_.st R
[Pharo-dev] Diffing while Merging Class Rename
It is difficult to see the actual changes when a merge includes a class rename, which just shows up as all methods removed from old class, and all methods created in new class. Is there a way to diff these methods? - Cheers, Sean -- View this message in context: http://forum.world.st/Diffing-while-Merging-Class-Rename-tp4807854.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] OSProcess bug ?
On Thu, Feb 26, 2015 at 1:10 AM, jannik laval jannik.la...@gmail.com wrote: Hi Dave, 2015-02-25 17:05 GMT+01:00 David T. Lewis le...@mail.msen.com: Hi Jannik, One other thing I just thought of: Check and see if your rostopic program is actually writing to standard output, as opposed to writing directly to /dev/tty. From a terminal window, I think you could do this: $ rostopic out.txt Yes, it writes on the file after a ctrl-c. Is that a hint? So if in one terminal you run $ rostopic out.txt then without hitting ctrl-c, in another terminal view the contents of out.txt, is it empty? Do you get different behaviour with this between each of these mode [1]?... - *Latching mode* - rostopic will publish a message to /topic_name and keep it *latched* -- any new subscribers that come online after you start rostopic will hear this message. You can stop this at any time by pressing ctrl-C. *Once mode* - If you don't want to have to stop rostopic with ctrl-C, you can publish in *once mode*. rostopic will keep the message latched for 3 seconds, then quit. *Rate mode*. - In rate mode, rostopic will publish your message at a specific rate. For example, -r 10 will publish at 10hz. For file and piped input, this defaults to 10hz. Options: - -l, --latch New in Diamondback - Enable latch mode. Latching mode is the *default* when using command-line arguments. -r RATE - Enable *rate mode*. Rate mode is the *default* (10hz) when using piped or file input. -1, --once - Enable *once mode*. cheers -ben [1] http://wiki.ros.org/rostopic#rostopic_pub [2] http://answers.ros.org/question/59070/disable-latching-for-rostopic-in-piping-mode/
[Pharo-dev] Slots: and ProcessLocalSlot
So I added an example of ProcessLocalSlot (like a thread local from other
languages) using the existing ProcessLocalVariable. A variable has
different values depending on the process the code is executing.
Example of usage:
Object subclass: #TestLocal
slots: { #local = ProcessLocalSlot }
classVariables: { }
category: 'SlotTestGuille'.
object := TestLocal new.
object local: 55.
object local.
[ valueInOtherProcess := object local ] fork.
valueInOtherProcess. = nil
[ object local: 'String'.
valueInOtherProcess := object local ] fork.
valueInOtherProcess. = 'String'
object local = 55
Code in issue: https://pharo.fogbugz.com/f/cases/15004/Add-ProcessLocalSlot
Guille
Re: [Pharo-dev] Slots: and ProcessLocalSlot
*Very* nice !
On 26 Feb 2015, at 18:55, Guillermo Polito guillermopol...@gmail.com wrote:
So I added an example of ProcessLocalSlot (like a thread local from other
languages) using the existing ProcessLocalVariable. A variable has different
values depending on the process the code is executing.
Example of usage:
Object subclass: #TestLocal
slots: { #local = ProcessLocalSlot }
classVariables: { }
category: 'SlotTestGuille'.
object := TestLocal new.
object local: 55.
object local.
[ valueInOtherProcess := object local ] fork.
valueInOtherProcess. = nil
[ object local: 'String'.
valueInOtherProcess := object local ] fork.
valueInOtherProcess. = 'String'
object local = 55
Code in issue: https://pharo.fogbugz.com/f/cases/15004/Add-ProcessLocalSlot
Guille
[Pharo-dev] GTSpotter - searching anywhere within identifiers
I want to use GTSpotter to discover the different types of slots, so I type slot but it only finds identifiers starting with slot, excluding items like IndexedSlot. I'd really like to not be constrained to only search at start of identifiers. Did Spotter use to search differently? (I can't remember). This is build 40513. cheers -ben
Re: [Pharo-dev] a lesson about pragma
On Fri, Feb 27, 2015 at 12:53 AM, Johan Fabry jfa...@dcc.uchile.cl wrote: I think that fundamentally you should not use pragmas for documentation. I guess that people use it to be able to provide minimal structure for their documentation. A better solution would be to have a simple convention for this kind of structure that is easy to parse, e.g using newlines to separate the ‘keywords’ and their ‘values’ and just have a comment. For example: Now: api: #block getter: #acceptBlock registration: #whenAcceptBlockChanged: Comment convention: “ api: #block getter: #acceptBlock registration: #whenAcceptBlockChanged: Easy to parse, and easy to write conversion logic for batch transformation of these comments. And MOST importantly, easy to identify that it doesn't affect program execution! cheers -ben On Feb 26, 2015, at 13:12, Ben Coman b...@openinworld.com wrote: Could you provide a sample, so this anti-pattern is more clear. cheers -ben On Fri, Feb 27, 2015 at 12:08 AM, stepharo steph...@free.fr wrote: We are cleaning spec and the fact that method selectors are used everywhere in pragmas as meta description makes the navigation terrible. I'm removing them to be able to understand who is really calling the methods. So there is probably a lesson there. Stef
Re: [Pharo-dev] GTSpotter - searching anywhere within identifiers
In the latest version from moose it also finds IndexedSlot if you type in 'slot'. However it displays at the beginning identifiers that start with the keyword. To find IndexedSlot you can type in 'slot' dive in the classes category and then search for 'index' Cheers, Andrei On Thu, Feb 26, 2015 at 6:09 PM, Ben Coman b...@openinworld.com wrote: I want to use GTSpotter to discover the different types of slots, so I type slot but it only finds identifiers starting with slot, excluding items like IndexedSlot. I'd really like to not be constrained to only search at start of identifiers. Did Spotter use to search differently? (I can't remember). This is build 40513. cheers -ben
[Pharo-dev] a lesson about pragma
We are cleaning spec and the fact that method selectors are used everywhere in pragmas as meta description makes the navigation terrible. I'm removing them to be able to understand who is really calling the methods. So there is probably a lesson there. Stef
Re: [Pharo-dev] instance variable rename is deeply broken....
On 26 Feb 2015, at 16:12, stepharo steph...@free.fr wrote: This was a BAD IDEA to rename naively accessors when we rename an instance variable. Now I cannot use instance renaming because of the ripple effects I do not control. And I just got an emergency evaluator when I simply wanted to rename an instance variable in ButtonModel :( Mark do you know if your changes go integrated? His changes where integrated, the undo of this not. Yes, we should remove this... Because now I will work without refactoring and I have all the spec classes to change. Not fun. Stef
Re: [Pharo-dev] Issue tracker: 13 issues to review
Sean P. DeNigris wrote Down to 10: Add one more: Issue 10741: Monticello - Can't upload slice dependency already in repo Fix in inbox: SLICE-Issue-10741-Cant-upload-slice-dependency-already-in-repo-SeanDeNigris.1 - MCCacheRepository#storeVersion: had a guard which skips file if it already exists; push it up to MCFileBasedRepository - Cheers, Sean -- View this message in context: http://forum.world.st/Issue-tracker-13-issues-to-review-tp4807759p4808024.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Recording user actions in GTools
Absolutely no problem for me. By the way, I even have no problem to divulge my identity if this help. Cheers, Alexandre On Feb 26, 2015, at 12:10 PM, Andrei Chis chisvasileand...@gmail.com wrote: Hi, In order to better understand how people use the GT tools we would like to integrate, before the Pharo code freeze, a small extension to GT tools (300 lines of code) that records and sends usage data. The recording of data will be opt-out: you have to explicitly agree with sending usage data. The first time you open a GT tool, that tool will embed a small UI asking you if you want to enable data submission. We will save the setting in the your preference directory so it will be shared between all your local images. You can change this setting at any time from the Settings Browser. For now we will only like to collect data about Spotter. By default we will only collect anonymous data about various actions you do in spotter (open, close, search, dive-in, dive-out, select element, etc) without collecting any data what about what query you enter or what search results you get. We would also add an optional setting for sending the query text and selected elements. We will send then the data periodically to our server and when you close the image. The data that will be send is rather small: 1000 actions require 7kb of data. Thus sending an entire day worth of recordings, if all you did that day was searching, should be around 1MB of data. The recording does not influence the performance of Spotter. Spotter already generates all events of interest as announcements. To enable recording we just register a subscriber with the Spotter announcer and store the events of interest. We would like to get your opinion on this. Cheers, GT team -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Recording user actions in GTools
On 26/02/15 16:10, Andrei Chis wrote: The recording of data will be opt-out: *you have to explicitly agree with sending usage data*. Uhhm. That's called opt-in. A practical issue: I have projects/images where it is absolutely no problem, and projects where I definitely don't want it. All local images is not a good setting. For certain directories would work. Stephan
Re: [Pharo-dev] Slots: and ProcessLocalSlot
Very very nice!
This is really cool.
Doru
On Thu, Feb 26, 2015 at 7:01 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
*Very* nice !
On 26 Feb 2015, at 18:55, Guillermo Polito guillermopol...@gmail.com
wrote:
So I added an example of ProcessLocalSlot (like a thread local from
other languages) using the existing ProcessLocalVariable. A variable has
different values depending on the process the code is executing.
Example of usage:
Object subclass: #TestLocal
slots: { #local = ProcessLocalSlot }
classVariables: { }
category: 'SlotTestGuille'.
object := TestLocal new.
object local: 55.
object local.
[ valueInOtherProcess := object local ] fork.
valueInOtherProcess. = nil
[ object local: 'String'.
valueInOtherProcess := object local ] fork.
valueInOtherProcess. = 'String'
object local = 55
Code in issue:
https://pharo.fogbugz.com/f/cases/15004/Add-ProcessLocalSlot
Guille
--
www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] zipped and unzipped methods for ByteArray
Why do we have to put everything in string? why Zip string: 'hello' Zip bzip string: 'hello' Zip gzip string: 'hello' would not be more modular? Zip could be a factory and have subclasses. This is not because can extend classes that we should think about nicer way. I like for example the DateFormatter strategy related to Date from other languages because I can specify the way I want it. Stef Le 25/2/15 16:52, Juraj Kubelka a écrit : 25. 2. 2015 v 12:28, Sven Van Caekenberghe s...@stfx.eu: This seems related to adding 'easy of use' methods to String. There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ? How much do we want to couple different parts of the system ? I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme. Cheers, Juraj On 25 Feb 2015, at 16:23, Juraj Kubelka juraj.kube...@gmail.com wrote: Can I add ByteArray#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example. Do you agree? Thanks, Juraj
[Pharo-dev] Rubric versus Athens
---BeginMessage--- Hello Nicolai, I’ve made a first pass. I’ve not used your Athens* add ons. Instead, raw Athens drawing. Less clean but done. Hope it will help to continue Athens integration. Cheers Alain ---End Message---
Re: [Pharo-dev] MCVersionInfo: 10% of the image
2015-02-26 7:58 GMT+01:00 Marcus Denker marcus.den...@inria.fr: On 25 Feb 2015, at 23:28, Thierry Goubier thierry.goub...@gmail.com wrote: Hi, I made a very simple experiment, with a MCLazyVersionInfo, which holds its ancestors and stepChildren in WeakArray(s), and loads it from repositories on demand. Installing it on Pharo 40511, and then flushing the Monticello package cache, reduces the image by around 5 MB: Nice! Marcus And it behaves as the non-lazy one. There are a few things to change GUI-side to avoid an unnecessary loading of the complete ancestry of all the packages in the image, but this is workable. I see two ways of using it: as an install, flush package cache before release and gain 5MB of RAM. If you start regularly developping (loading packages, etc...) then new packages will revert to non-lazy version info (without: 'please wait, I'm loading ancestry' moments). as a permanent change in MC. The change is a bit more intrusive (need to change how working copies are created) but, well, as long as the worked on packages are inside the in-memory MC package cache, behavior is exactly the same as a non-lazy version info. As you prefer. I added an issue: https://pharo.fogbugz.com/default.asp?14997 Thierry
Re: [Pharo-dev] MCVersionInfo: 10% of the image
And it behaves as the non-lazy one. There are a few things to change GUI-side to avoid an unnecessary loading of the complete ancestry of all the packages in the image, but this is workable. I see two ways of using it: as an install, flush package cache before release and gain 5MB of RAM. If you start regularly developping (loading packages, etc...) then new packages will revert to non-lazy version info (without: 'please wait, I'm loading ancestry' moments). as a permanent change in MC. The change is a bit more intrusive (need to change how working copies are created) but, well, as long as the worked on packages are inside the in-memory MC package cache, behavior is exactly the same as a non-lazy version info. As you prefer. My focus is that we ship an image that is not growing indefinitely… so this means it needs to be part of the release. I don’t care too much that the image is large when I work, but it should not come with all this data in memory when it can be calculated (or lazyly loaded) when needed. I added an issue: https://pharo.fogbugz.com/default.asp?14997 https://pharo.fogbugz.com/default.asp?14997 Thanks! Marcus
Re: [Pharo-dev] MCVersionInfo: 10% of the image
Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Thierry 2015-02-26 9:33 GMT+01:00 Marcus Denker marcus.den...@inria.fr: And it behaves as the non-lazy one. There are a few things to change GUI-side to avoid an unnecessary loading of the complete ancestry of all the packages in the image, but this is workable. I see two ways of using it: as an install, flush package cache before release and gain 5MB of RAM. If you start regularly developping (loading packages, etc...) then new packages will revert to non-lazy version info (without: 'please wait, I'm loading ancestry' moments). as a permanent change in MC. The change is a bit more intrusive (need to change how working copies are created) but, well, as long as the worked on packages are inside the in-memory MC package cache, behavior is exactly the same as a non-lazy version info. As you prefer. My focus is that we ship an image that is not growing indefinitely... so this means it needs to be part of the release. I don't care too much that the image is large when I work, but it should not come with all this data in memory when it can be calculated (or lazyly loaded) when needed. I added an issue: https://pharo.fogbugz.com/default.asp?14997 Thanks! Marcus
Re: [Pharo-dev] Using Pharo to Save Human Life
Hi Alexandre, Thank you very much, we have just started and there is still much work to be done. Of course, we will ask pharo community if we need help ... Regards, Onil On Thu, Feb 26, 2015 at 2:50 AM, Alexandre Bergel alexandre.ber...@me.com wrote: Yeah, I have changed the subject for a more accurate one. Onil, you are doing a fantastic work: monitoring flood in Jakarta in real time is impressive. I have enjoyed very much your presentation. Pity the network did not work, but the effect is still very strong. I feel humble and respectful when I see your goal and vision. I am happy that we, as a community, are able to help you. And really, feel free to complain about the system you are using. Just ask for help if you need. Big big clap I would love to see your presentation at ESUG. Alexandre On Feb 25, 2015, at 5:07 PM, stephan step...@stack.nl wrote: The first FOSDEM video has arrived: http://mirrors.dotsrc.org/fosdem/2015/devroom-smalltalk/cirela.mp4 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Onil Goubier Engineer CIRELA Association Communication and Information technology for REsiLience to disAsters and climate change 25, rue Paulhan 78140 Vélizy-Villacoublay, France Ph. +33 6 67 77 49 93
Re: [Pharo-dev] MCVersionInfo: 10% of the image
2015-02-26 10:44 GMT+01:00 Marcus Denker marcus.den...@inria.fr: On 26 Feb 2015, at 10:15, Thierry Goubier thierry.goub...@gmail.com wrote: Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Works fine with merge, too. The 511 image is 23.2MB after. This means with the Scriptloader fix from 510 together we would over 10MB... or nearly 1/3. Nice! Ok. Second scheme (get it to work everywhere, everytime) seems to just need to change MCWorkingAncestryaddAncestor: and MCWorkingCopy addStepChild: Thierry Marcus
Re: [Pharo-dev] MCVersionInfo: 10% of the image
2015-02-26 10:51 GMT+01:00 Thierry Goubier thierry.goub...@gmail.com: 2015-02-26 10:44 GMT+01:00 Marcus Denker marcus.den...@inria.fr: On 26 Feb 2015, at 10:15, Thierry Goubier thierry.goub...@gmail.com wrote: Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Works fine with merge, too. The 511 image is 23.2MB after. This means with the Scriptloader fix from 510 together we would over 10MB... or nearly 1/3. Nice! Ok. Second scheme (get it to work everywhere, everytime) seems to just need to change MCWorkingAncestryaddAncestor: and MCWorkingCopy addStepChild: Done. Slice uploaded.Tried with loading Roassal2, then flushing the Monticello package cache: MCVersionInfo allInstances size 2 Thierry Thierry Marcus
Re: [Pharo-dev] How Far We've Come!
Thanks Sean And I would love to have a nice catalog and easier dependency expression. BTW: You should really have a look at Block :) I can tell you :) because now it is stable and starts to be really sexy. Stef Le 24/2/15 22:28, Sean P. DeNigris a écrit : It was so much fun watching the Pharo Days videos! Thanks for recording them and I hope to be there next time :) Somewhere halfway through the playlist, it hit me how easily I was downloading all the projects and images being talked about. I was copy/pasting one-line Metacello scripts out of github READMEs, clicking in the Configuration Browser, or downloading the latest code from CI - and it all just worked!!! Remember not too long ago when we were passing around custom scripts to load multiple dependent packages, and explaining to outsiders that we don't need github because Smalltalk invented SCM (or whatever) while we created the future invisibly, hidden away from the rest of the world? After laying down so many building blocks (like FileSystem) that take the system out of the way of creative expression, it is exciting to finally be tackling some of the high-impact things... you know the ones we've been avoiding... like Morphic, development tools, and the text editors. And the steady streams of new talent and funding seem likely to keep the successes coming. So CONGRATULATIONS, Pharo Community We deserve it. Now get back to work - we've got a future to create ;) - Cheers, Sean -- View this message in context: http://forum.world.st/How-Far-We-ve-Come-tp4807408.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] MCVersionInfo: 10% of the image
On 26 Feb 2015, at 10:15, Thierry Goubier thierry.goub...@gmail.com wrote: Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Works fine with merge, too. The 511 image is 23.2MB after. This means with the Scriptloader fix from 510 together we would over 10MB… or nearly 1/3. Nice! Marcus
Re: [Pharo-dev] MCVersionInfo: 10% of the image
On 26 Feb 2015, at 11:11, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-26 10:51 GMT+01:00 Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com: 2015-02-26 10:44 GMT+01:00 Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr: On 26 Feb 2015, at 10:15, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Ok, a first slice is in, it's the first solution for now (second is just extending the scheme). Loading the slice should install the lazy version and flush the caches (does merging would initialize the class?) Works fine with merge, too. The 511 image is 23.2MB after. This means with the Scriptloader fix from 510 together we would over 10MB… or nearly 1/3. Nice! Ok. Second scheme (get it to work everywhere, everytime) seems to just need to change MCWorkingAncestryaddAncestor: and MCWorkingCopy addStepChild: Done. Slice uploaded.Tried with loading Roassal2, then flushing the Monticello package cache: MCVersionInfo allInstances size 2 Thanks!! Marcus
Re: [Pharo-dev] Recording user actions in GTools
26. 2. 2015 v 19:04, Peter Uhnák i.uh...@gmail.com: before the Pharo code freeze, a small extension to GT tools (300 lines of code) that records and sends usage data. various actions you do in spotter (open, close, search, dive-in, dive-out, select element, etc) If there are no tooltips what shortcuts to use people cannot dive-in and there is nothing to record :)... so please please :) There are already tooltips, but likely in a version which is about to be released for Pharo 4: You can try Moose 5.1 for now. Cheers, Juraj
Re: [Pharo-dev] The evil twin in 40516
This is excellent! On Feb 26, 2015, at 20:07, Marcus Denker marcus.den...@inria.fr wrote: Hi, In 40516 there is now a strange, but rather powerful mechanism for CompiledMethod: the Twin. What does that do? you can call on a method #createTwin (ReflectivityExamples#exampleMethod) createTwin. after this, the CompiledMethod has a high-level representation (the AST) attached that itself references the CompiledMethod (they form a twin). (ReflectivityExamples#exampleMethod) reflectiveMethod The fun thing is now that one can install either in the class. Call #invalidate to make sure the reflective method is installed. ReflectiveMethod implements #run:with:in: which calls a compilation hook (too re-create from the AST) and then installs that in the method dict and then executes the method: (ReflectivityExamples#exampleMethod) createTwin. (ReflectivityExamples#exampleMethod) invalidate. self assert: (ReflectivityExamples#exampleMethod) class = ReflectiveMethod. self assert: ReflectivityExamples new exampleMethod = 5. self assert: (ReflectivityExamples#exampleMethod) class = CompiledMethod. Which means that this gives us an in-image, on-demand JIT compiler AST-Bytecode. In 50 lines of code. e.g. try on Morph: Morph methods do: #createTwin. Morph methods do: #invalidate. Counting which twin is installed shows us the working set of Morph: (Morph methods select: [ :each | each class = CompiledMethod ]) size some 330 method out of nearly 900…. So what can one do with this? In essence this turns the AST into a reflective representation for Methods (if you care to set up twin creation + invalidation correctly). What will this allow us to do? stay tuned... Marcus --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
[Pharo-dev] The evil twin in 40516
Hi, In 40516 there is now a strange, but rather powerful mechanism for CompiledMethod: the Twin. What does that do? you can call on a method #createTwin (ReflectivityExamples#exampleMethod) createTwin. after this, the CompiledMethod has a high-level representation (the AST) attached that itself references the CompiledMethod (they form a twin). (ReflectivityExamples#exampleMethod) reflectiveMethod The fun thing is now that one can install either in the class. Call #invalidate to make sure the reflective method is installed. ReflectiveMethod implements #run:with:in: which calls a compilation hook (too re-create from the AST) and then installs that in the method dict and then executes the method: (ReflectivityExamples#exampleMethod) createTwin. (ReflectivityExamples#exampleMethod) invalidate. self assert: (ReflectivityExamples#exampleMethod) class = ReflectiveMethod. self assert: ReflectivityExamples new exampleMethod = 5. self assert: (ReflectivityExamples#exampleMethod) class = CompiledMethod. Which means that this gives us an in-image, on-demand JIT compiler AST-Bytecode. In 50 lines of code. e.g. try on Morph: Morph methods do: #createTwin. Morph methods do: #invalidate. Counting which twin is installed shows us the working set of Morph: (Morph methods select: [ :each | each class = CompiledMethod ]) size some 330 method out of nearly 900…. So what can one do with this? In essence this turns the AST into a reflective representation for Methods (if you care to set up twin creation + invalidation correctly). What will this allow us to do? stay tuned... Marcus
Re: [Pharo-dev] The evil twin in 40516
Wow!!! This means that one can call #createTwin, modify the AST, and simply call it! Impressive!!! Is it per default in Pharo 40516? Alexandre On Feb 26, 2015, at 8:07 PM, Marcus Denker marcus.den...@inria.fr wrote: Hi, In 40516 there is now a strange, but rather powerful mechanism for CompiledMethod: the Twin. What does that do? you can call on a method #createTwin (ReflectivityExamples#exampleMethod) createTwin. after this, the CompiledMethod has a high-level representation (the AST) attached that itself references the CompiledMethod (they form a twin). (ReflectivityExamples#exampleMethod) reflectiveMethod The fun thing is now that one can install either in the class. Call #invalidate to make sure the reflective method is installed. ReflectiveMethod implements #run:with:in: which calls a compilation hook (too re-create from the AST) and then installs that in the method dict and then executes the method: (ReflectivityExamples#exampleMethod) createTwin. (ReflectivityExamples#exampleMethod) invalidate. self assert: (ReflectivityExamples#exampleMethod) class = ReflectiveMethod. self assert: ReflectivityExamples new exampleMethod = 5. self assert: (ReflectivityExamples#exampleMethod) class = CompiledMethod. Which means that this gives us an in-image, on-demand JIT compiler AST-Bytecode. In 50 lines of code. e.g. try on Morph: Morph methods do: #createTwin. Morph methods do: #invalidate. Counting which twin is installed shows us the working set of Morph: (Morph methods select: [ :each | each class = CompiledMethod ]) size some 330 method out of nearly 900…. So what can one do with this? In essence this turns the AST into a reflective representation for Methods (if you care to set up twin creation + invalidation correctly). What will this allow us to do? stay tuned... Marcus -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40516 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 657ef3: 40516
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 657ef34022736524166273d950d8b0adcb6f691a https://github.com/pharo-project/pharo-core/commit/657ef34022736524166273d950d8b0adcb6f691a Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-02-26 (Thu, 26 Feb 2015) Changed paths: R KernelTests.package/DelayTest.class/instance/testing/testSemaphore.st A KernelTests.package/DelayTest.class/instance/testing/testSemaphoreNoTimeout.st A KernelTests.package/DelayTest.class/instance/testing/testSemaphoreTimeout.st R KernelTests.package/DelayTest.class/instance/testing/testTimeoutSemaphoreAfterMSecs.st A Reflectivity.package/MetaLink.class/README.md A Reflectivity.package/MetaLink.class/definition.st A Reflectivity.package/MetaLink.class/instance/accessing/metaObject.st A Reflectivity.package/MetaLink.class/instance/accessing/metaObject_.st A Reflectivity.package/MetaLink.class/instance/accessing/selector.st A Reflectivity.package/MetaLink.class/instance/accessing/selector_.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/destroyTwin.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script515.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script516.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40515.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40516.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/MetaLink.class/README.md R Slot.package/MetaLink.class/definition.st R Slot.package/MetaLink.class/instance/accessing/metaObject.st R Slot.package/MetaLink.class/instance/accessing/metaObject_.st R Slot.package/MetaLink.class/instance/accessing/selector.st R Slot.package/MetaLink.class/instance/accessing/selector_.st A Slot.package/ProcessLocalSlot.class/README.md A Slot.package/ProcessLocalSlot.class/definition.st A Slot.package/ProcessLocalSlot.class/instance/code generation/emitStore_.st A Slot.package/ProcessLocalSlot.class/instance/code generation/emitValue_.st A Slot.package/ProcessLocalSlot.class/instance/initialization/initialize_.st A Slot.package/ProcessLocalSlot.class/instance/meta-object-protocol/read_.st A Slot.package/ProcessLocalSlot.class/instance/meta-object-protocol/wantsInitalization.st A Slot.package/ProcessLocalSlot.class/instance/meta-object-protocol/write_to_.st A Slot.package/PropertySlot.class/instance/code generation/emitStore_.st A Slot.package/PropertySlot.class/instance/code generation/emitValue_.st M Slot.package/Slot.class/instance/meta-object-protocol/link_.st R Slot.package/WeakSlot.class/instance/as yet unclassified/emitStore_.st R Slot.package/WeakSlot.class/instance/as yet unclassified/emitValue_.st R Slot.package/WeakSlot.class/instance/as yet unclassified/initialize_.st R Slot.package/WeakSlot.class/instance/as yet unclassified/read_.st R Slot.package/WeakSlot.class/instance/as yet unclassified/wantsInitalization.st R Slot.package/WeakSlot.class/instance/as yet unclassified/write_to_.st A Slot.package/WeakSlot.class/instance/code generation/emitStore_.st A Slot.package/WeakSlot.class/instance/code generation/emitValue_.st A Slot.package/WeakSlot.class/instance/initialization/initialize_.st A Slot.package/WeakSlot.class/instance/meta-object-protocol/read_.st A Slot.package/WeakSlot.class/instance/meta-object-protocol/wantsInitalization.st A Slot.package/WeakSlot.class/instance/meta-object-protocol/write_to_.st Log Message: --- 40516 14990 MonitorDelay#signalLock:afterMSecs:inMonitor:queue: should return MonitorDelay object https://pharo.fogbugz.com/f/cases/14990 15003 Bytecode Gen for Property Slot + small fixes reflectivity https://pharo.fogbugz.com/f/cases/15003 15004 Add ProcessLocalSlot https://pharo.fogbugz.com/f/cases/15004 http://files.pharo.org/image/40/40516.zip
Re: [Pharo-dev] Recording user actions in GTools
before the Pharo code freeze, a small extension to GT tools (300 lines of code) that records and sends usage data. various actions you do in spotter (open, close, search, dive-in, dive-out, select element, etc) If there are no tooltips what shortcuts to use people cannot dive-in and there is nothing to record :)... so please please :) But I certainly don't mind. Peter
Re: [Pharo-dev] The evil twin in 40516
Cool! (spotter does not work on this methods, do we have to change this in the class ReactiveMethod or spotter?)
Re: [Pharo-dev] The evil twin in 40516
Oh and inspecting the ReflectiveMethod ast with GTInspector has some strange effect 2015-02-27 0:24 GMT+01:00 Nicolai Hess nicolaih...@web.de: Cool! (spotter does not work on this methods, do we have to change this in the class ReactiveMethod or spotter?)
Re: [Pharo-dev] zipped and unzipped methods for ByteArray
2015-02-26 22:37 GMT+01:00 stepharo steph...@free.fr: Why do we have to put everything in string? why Zip string: 'hello' Zip bzip string: 'hello' Zip gzip string: 'hello' would not be more modular? Zip could be a factory and have subclasses. This is not because can extend classes that we should think about nicer way. I like for example the DateFormatter strategy related to Date from other languages because I can specify the way I want it. Stef Because somehow you can easily pipe unary messages. ^'hello' zipped base64Encoded versus: (Encoder base64 byteArray: (Zip gzip string: 'hello')). I much much prefer to read/maintain 1st version The 2nd one looks like overkill verbiage to me. Le 25/2/15 16:52, Juraj Kubelka a écrit : 25. 2. 2015 v 12:28, Sven Van Caekenberghe s...@stfx.eu: This seems related to adding 'easy of use' methods to String. There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ? How much do we want to couple different parts of the system ? I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme. Cheers, Juraj On 25 Feb 2015, at 16:23, Juraj Kubelka juraj.kube...@gmail.com wrote: Can I add ByteArray#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example. Do you agree? Thanks, Juraj
Re: [Pharo-dev] The evil twin in 40516
On 27 Feb 2015, at 00:24, Nicolai Hess nicolaih...@web.de wrote: Cool! (spotter does not work on this methods, do we have to change this in the class ReactiveMethod or spotter?) we need to copy the methods over… Marcus
Re: [Pharo-dev] Bug? JPEG reading ignores EXIF Orientation
stepharo wrote We should improve the Image support because it is dated. I've always found the replace me with aTransformMorph on resize thing baffling, so I started re-implementing a bare-bones SimpleImageMorph. Right now it holds onto the original form unaltered, but warps it to its inner bounds, and you can also specify to fix the aspect ratio. For the simple cases that cover 99% of my usage, it works perfectly. See https://github.com/seandenigris/SimpleImageMorph for more info. - Cheers, Sean -- View this message in context: http://forum.world.st/Bug-JPEG-reading-ignores-EXIF-Orientation-tp4807446p4808124.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Recording user actions in GTools
There are already tooltips, but likely in a version which is about to be released for Pharo 4: You can try Moose 5.1 for now. Ah! I was looking at Pharo image; yes, this is what I was looking for. :) Peter
Re: [Pharo-dev] The evil twin in 40516
On 27 Feb 2015, at 00:15, Alexandre Bergel alexandre.ber...@me.com wrote: Wow!!! This means that one can call #createTwin, modify the AST, and simply call it! Impressive!!! You need to handle invalidation yourself, too. (for now). I want to first concentrate on purely “annotation” based MOP: instead of changing the AST it is annotated with MetaLinks. When a link is set, the twin creation + invalidation happens. When the last Link is removed, the twin disappears automatically. Is it per default in Pharo 40516? Yes. Marcus
Re: [Pharo-dev] The evil twin in 40516
On 27 Feb 2015, at 00:26, Marcus Denker marcus.den...@inria.fr wrote: On 27 Feb 2015, at 00:15, Alexandre Bergel alexandre.ber...@me.com wrote: Wow!!! This means that one can call #createTwin, modify the AST, and simply call it! Impressive!!! You need to handle invalidation yourself, too. (for now). I want to first concentrate on purely “annotation” based MOP: instead of changing the AST it is annotated with MetaLinks. When a link is set, the twin creation + invalidation happens. When the last Link is removed, the twin disappears automatically. Is it per default in Pharo 40516? Yes. and it does not yet recompile… recompileAST self flag: #TBD. compile the AST” :-)
[Pharo-dev] Easy way to write a proxy?
Hi! I have a near-to-be naive question. Maybe there is something obvious, but I cannot see it. Consider the following implementation of a proxy: -=-=-=-=-=-=-=-=-=-=-=-= Object subclass: #MyProxy instanceVariableNames: 'object'. MyProxy object: anObject object := anObject MyProxy doesNotUnderstand: aMessage ^ object perform: aMessage selector withArguments: aMessage arguments Object wrap self becomeForward: (MyProxy new object: self; yourself) -=-=-=-=-=-=-=-=-=-=-=-= The problem is with wrap. After the becomeForward:, MyProxy has itself in the object variable. Even self is apparently subject to the #become. It means that the following code loop indefinitely -=-=-=-=-=-=-=-=-=-=-=-= d := Dictionary new. d wrap. d add: #foo - 10 -=-=-=-=-=-=-=-=-=-=-=-= I know there is Mariano’s library to write proxy. But I still wondering whether this could be done simply. Any idea how to simply create a proxy? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
