Re: [Pharo-dev] Killing respondsTo:
+1 Doru On May 14, 2013, at 10:27 PM, stephane ducasse stephane.duca...@free.fr wrote: why do we want to introduce a bad slow type system on certain single place? Why a UI element would have to check that a given instance can do something while we never ever do it in any other places. if we have a button and its label should be able to answer the message enabled then we display the button and send the message enabled. If it crashes then this is the programmer' fault. He should provide an object that responds to enabled but we do not test it. And we should have nice polymorphic objects and not string and nil and color why not array with hexa decimal colors? Being reasonable programmers and not kids wanted to plug anything anyhow is the way to build nice system (and polymorphic objects). Stef On 14 May 2013 16:21, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I'm in favor killing all the respondsTo: acceptTextMorphs Accept any text morphs except for those that have no edits. self allMorphs do: [:p | ((p respondsTo: #accept) and: [ (p respondsTo: #hasUnacceptedEdits) and: [ p hasUnacceptedEdits]]) ifTrue: [p accept]] They're a step up from #isKindOf:. It looks like you need is something that says does this object respond to a particular set of messages (i.e., a Protocol)?. (No, Nicolas, I don't mean a message category! :) ) But in this particular case the solution looks like making a #insertADecentNameHere that particular classes of things can implement as ^ self hasUnacceptedEdits ifTrue: [self accept] frank -- www.tudorgirba.com Things happen when they happen, not when you talk about them happening.
Re: [Pharo-dev] TxText new version 0.8
Yes, I think this is good at this point. When the mapping will disappear, things will become simpler. Doru On Thu, May 23, 2013 at 8:11 AM, Denis Kudriashov dionisi...@gmail.comwrote: 2013/5/22 Tudor Girba tu...@tudorgirba.com So, the pattern I know of is to put the Tests as a discriminator before the variable part of your code. So, something like: - BaseName-Core - BaseName-Tests-Core It is exactly my pattern but with dash before Tests word: -TxText-Model -TxTextTests-Model -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] TxText new version 0.8
Not even for Moose it makes sense to deploy without tests :) Doru On Thu, May 23, 2013 at 9:18 AM, Camillo Bruni camillobr...@gmail.comwrote: technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general And I don't have it at production because I don't have changes file here. yet you load them. so I wonder if it makes sense to even load tests separately? It make sense when you try to reduce production image size. And loading only required packages (without tests) works well. Why change it? I know that this scheme is in use, but why? why do I have to reduce the size of a production image? from how many to many megabytes? It might make sense for moose, but none of the other projects. Do you really care if the image is 35 instead of 25MB? To me this argument sounds invalid :/ -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Ann] New TxText version 1.0
I tried to load it, but could not because in the sig repository, the latest
version of the configuration is still 0.6.
Cheers,
Doru
On May 26, 2013, at 11:09 PM, Denis Kudriashov dionisi...@gmail.com wrote:
Hello.
I finish edit validation logic. So new version 1.0 is available:
Gofer it
url: 'http://www.smalltalkhub.com/#!/~sig/TxText';
package: 'ConfigurationOfTxText';
load.
((Smalltalk at: #ConfigurationOfTxText) project version: '1.0') load:
#('ALL').
TxEditValidator is introduced for TxEditor. It validates changes performed by
given block.
It asks editor to try changes from this block. And if changed text satisfied
text spec validator executes given block to apply changes.
Few text specs implemented:
-TxAnyTextSpec
-TxDigitalTextSpec
-TxDecimalTextSpec
More example of text specs are at TxTextMorph class side:
- mask with digits only
- smart numbers which accept only decimal numbers:
m := TxTextMorph new.
m editDecorator: TxSingleLineEditDecorator smartNumbers.
m textSpec: (TxDecimalTextSpec maxDecimalDigits: 3).
m newTextContents: '1000'.
m addCursor.
m beEditable.
m openInHand
Best regards.
Denis.
--
www.tudorgirba.com
Problem solving efficiency grows with the abstractness level of problem
understanding.
Re: [Pharo-dev] [Ann] New TxText version 1.0
Hi,
I found the issue: the url from the Gofer script was wrong :).
Here is the correct one:
Gofer it
url: 'http://www.smalltalkhub.com/mc/sig/TxText/main';
package: 'ConfigurationOfTxText';
load.
((Smalltalk at: #ConfigurationOfTxText) project version: '1.0') load:
#('ALL').
Cheers,
Doru
On May 27, 2013, at 6:44 AM, Denis Kudriashov dionisi...@gmail.com wrote:
2013/5/27 Tudor Girba tu...@tudorgirba.com
I tried to load it, but could not because in the sig repository, the latest
version of the configuration is still 0.6.
It works for me. I use Pharo 2.0 on Windows 7.
And you can see by webbrowser all versions exist at smalltalkhub repository
http://www.smalltalkhub.com/#!/~sig/TxText
Cheers,
Doru
On May 26, 2013, at 11:09 PM, Denis Kudriashov dionisi...@gmail.com wrote:
Hello.
I finish edit validation logic. So new version 1.0 is available:
Gofer it
url: 'http://www.smalltalkhub.com/#!/~sig/TxText';
package: 'ConfigurationOfTxText';
load.
((Smalltalk at: #ConfigurationOfTxText) project version: '1.0') load:
#('ALL').
TxEditValidator is introduced for TxEditor. It validates changes performed
by given block.
It asks editor to try changes from this block. And if changed text
satisfied text spec validator executes given block to apply changes.
Few text specs implemented:
-TxAnyTextSpec
-TxDigitalTextSpec
-TxDecimalTextSpec
More example of text specs are at TxTextMorph class side:
- mask with digits only
- smart numbers which accept only decimal numbers:
m := TxTextMorph new.
m editDecorator: TxSingleLineEditDecorator smartNumbers.
m textSpec: (TxDecimalTextSpec maxDecimalDigits: 3).
m newTextContents: '1000'.
m addCursor.
m beEditable.
m openInHand
Best regards.
Denis.
--
www.tudorgirba.com
Problem solving efficiency grows with the abstractness level of problem
understanding.
--
www.tudorgirba.com
Quality cannot be an afterthought.
Re: [Pharo-dev] Reflectivity beta
Indeed, this would be fantastic :) Doru On Fri, May 31, 2013 at 9:45 AM, Camille Teruel camille.ter...@gmail.comwrote: On 31 mai 2013, at 09:03, Norbert Hartl wrote: Sounds great! What happens if a method is recompiled. All metalinks are gone then? Yes indeed. If you have the method: foo self bar with a metalink on the message node and you recompile it to: foo self qux; bar; bar. then it is hard to tell which node(s) should adopt the metalink because there is no way to tell which #bar message of the second version is the one from the first version. I would love to have an editor where you manipulates ast nodes directly. With such an editor the developer would have feedback of where the metalinks are. In the underlying model, AST nodes would have an equivalence relation to say whether two nodes are different versions the same or not. This model could also be really useful for versioning and diff too. Norbert Am 30.05.2013 um 18:15 schrieb Camille Teruel camille.ter...@gmail.com: Hello everyone, Reflectivity beta is out ! Reflectivity is a tool that permit to annotate AST nodes with metalinks. You can put metalinks at different positions: - before: the metalink is executed before the node - instead: the metalink is executed instead the node - after: the metalink is executed after the node - onError: the metalink is executed only if the execution of the node raises an error - onSuccess: the metalink is executed only if the execution of the node raises no error When you put metalinks on some node of a method's AST, a wrapper is installed in place of the method. When executed, this wrapper compiles an expanded version of the AST that takes metalinks into account and install the resulting compiled method. Examples: increaseAllNumbersIn: aCompiledMethod A method that increases all numbers in aCompiledMethod aCompiledMethod reflectiveAST forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ] putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString ]. removeMetalinksIn: aCompiledMethod aCompiledMethod reflectiveAST removeAllMetalinks In nautilus, you have a menu entry called 'Edit metalinks' that permit to edit the metalinks of the node corresponding to the selected piece of code. As an example use case, another entry called 'Put breakpoint' adds a metalink that corresponds to 'Halt now' before the selected node. Remember that it is a beta, so you might find errors and things are likely to change. You can load Reflectivity with: Gofer it smalltalkhubUser: 'RMoD' project: 'Reflectivity'; configuration; loadDevelopment Or you can download it from RMoD's CI: https://ci.inria.fr/rmod/job/Reflectivity/ Camille -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] using fogbugz for other projects (like moose)
Hi, Would it be possible and desired, to open the Pharo fogbugz infrastructure for other related projects? Namely, I am thinking of Moose, in particular given that various issues are directly relevant for Pharo as well? For projects like Moose, this would imply less costs. The question is if something in this direction is even desired. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Lowecase class names
+1 Doru On May 31, 2013, at 3:47 PM, Marcus Denker marcus.den...@inria.fr wrote: On May 31, 2013, at 1:32 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi is there any reason why class builder does not allow lowercase classnames? Underscore is allowed, though. In the past people started too add check to make sure that we only use the naming that people are supposed to use. The place these checks where placed was the class builder. Over time it has shown that this is not good: it has do be done on a higher level. (we already removed certain checks, e.g. about variable capitalization). We should at some point introduce something that does these kinds of checks for the tools, but allows one to just do anything when needed at the lower level… Marcus -- www.tudorgirba.com It's not what we do that matters most, it's how we do it.
Re: [Pharo-dev] Rubric screencast
Good job, Alain! Here is the script for people that want to try it out (I tried it and it works in Pharo 2.0): Gofer new url: 'http://www.smalltalkhub.com/mc/AlainPlantec/Rubric/main'; package: 'Rubric'; load. Doru On Jun 1, 2013, at 5:38 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: alex there is only one package on smalltalkhub/alainplantec On Jun 1, 2013, at 2:40 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Any script to load Rubric? Alexandre On 1 Jun 2013, at 02:13, plantec alain.plan...@yahoo.com wrote: On 1 juin 2013, at 01:48, Igor Stasenko siguc...@gmail.com wrote: On 1 June 2013 01:25, Alexandre Bergel alexandre.ber...@me.com wrote: Hi Alain! Impressive! Very. But only feature-wise. Speed-wise is not. Is it related to recording? yes, my computer is slow and the screen recording make it inresponsive hoping that live version faster. just try it :) But I think there is a lot of place for improvement: A selection is a PolygonMorph. Maybe a dedicated version should be done. Cheers Alain -- Best regards, Igor Stasenko. -- www.tudorgirba.com Problem solving should be focused on describing the problem in a way that makes the solution obvious.
Re: [Pharo-dev] about Announcement weak on: do:
Indeed, the main reason why announcers were not made weak by default was that the weak code only worked for message sends but not for blocks. It would be great to have the blocks working, too. Doru On Jun 2, 2013, at 2:13 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi igor after our discussions about the fact that we should not use weak with block, I checked and WeakSubscriptionBuilderon: anAnnouncementClass do: aValuable ^ self subscribe: anAnnouncementClass do: aValuable Does not look like raising error. Stef -- www.tudorgirba.com Presenting is storytelling.
[Pharo-dev] get.moosetechnology.org
Hi, Andrei joined Camillo and extended a bit the ZeroConf infrastructure to make it easy for other projects to generate install scripts. As a consequence, we now have: http://get.moosetechnology.org The Moose-specific customization code can be found in the Moose-Development-Tools package from: http://www.smalltalkhub.com/mc/Moose/Moose/main The scripts are generated via the Pharo command line like: Pharo/pharo-ui moose-latest-dev-4.8.image moosezeroconf Cheers, Doru -- www.tudorgirba.com No matter how many recipes we know, we still value a chef.
Re: [Pharo-dev] MetacelloRepository
Which is a good thing :)
Thanks,
Doru
On Tue, Jun 4, 2013 at 9:28 AM, Stéphane Ducasse
stephane.duca...@inria.frwrote:
On Jun 4, 2013, at 7:18 AM, Hilaire Fernandes hilaire.fernan...@gmail.com
wrote:
Stephane,
The lack for me was the configurationOfXML with the XML-Parser version I
use (#20, a bit old).
As this is problably limited to my sistuation I recreate a
configurationOfXML in my own repo.
Btw, I use XML-Parser for both read and write of XML file.
Was XML-support splited in two packages recently?
yes
Normally when loading the parser you would get the writer but damien cut
it apart.
Stef
Thanks
Hilaire
Le 03/06/2013 22:08, Stéphane Ducasse a écrit :
Hilaire
Normally this is XMLParser. I extracted just the XML parser and not all
the tools.
Now if you want to write you have XMLWriter.
Let us know if it works.
Stef
On Jun 3, 2013, at 10:17 AM, Hilaire Fernandes
hilaire.fernan...@gmail.com wrote:
Hello,
To build DrGeo I use the squeaksource MetacelloRepository (example
bellow).
I can not find it in SmalltalkHub?
I can see in PahroExtra/XMLParser ConfigurationOfXMLParser, is it the
same as ConfigurationOfXMLSupport. Can I find equivalent of
ConfigurationOfXMLSupport matching the exact same XML source version?
Unhelpful, I did not find how to browse the source form Smalltalkhub to
explore online the ConfigurationOf... code.
Thanks
Hilaire
baseline1012: spec
version: '10.12-baseline'
spec for: #pharo do: [
spec blessing: #baseline.
spec project: 'XML Parser' with: [
spec className: 'ConfigurationOfXMLSupport';
version: '1.0.1';
loads: #('default');
file: 'ConfigurationOfXMLSupport';
repository: '
http://www.squeaksource.com/MetacelloRepository'].
spec package: 'DrGeoII-Core' with: [
spec requires: 'XML Parser']]
--
Dr. Geo - http://drgeo.eu
--
Dr. Geo - http://drgeo.eu
--
www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] [Screencast]: Pharo Smalltalk's New TxText: The Power of Clean Code
This is elegant :) Doru On Thu, Jun 6, 2013 at 9:21 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: So cool :) something like that ? :) smalltalkCodeWithStabilo self smalltalkCodeWithStabilo | area seg code | area := RubEditingArea new beWrapped; width: 400; updateTextWith: (code := self someSmallSmalltalkCode). area addSegment: (seg := RubPlainSegmentMorph inTextArea: area from: 3 to: code size). seg color: (Color yellow). seg borderColor: (Color orange alpha: 0.5). seg beSmoothCurve. area openInWorld Alain stabilo-selection.png -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] taking a custom screenshot of a submorph
Hi, Just in case you want to take a screenshot of a submorph, here is a description + video of how you can do it using the GTInspector: http://www.humane-assessment.com/blog/custom-morph-screenshot-with-gtinspector Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Modification on CollectionsExtensions
Moose is running (smoothly :)) on Pharo 2.0 since several months now. The idea is to merge the efforts to have more people working on top of the latest Pharo. There are two reasons for it: - first, we are too small of a community to split our efforts - second, often the Moose projects are directly relevant for Pharo and the other way around Cheers, Doru -- www.tudorgirba.com Every thing has its own flow. On 13.06.2013, at 23:24, Sean P. DeNigris s...@clipperadams.com wrote: Tudor Girba-2 wrote We will release Moose at the end of this month and we will move to Pharo 3.0 I'm impressed! Did you move Moose to Pharo 2.0 before it was released? I have been hesitant to move my projects to the alpha/beta versions because we are making so much progress (i.e. breaking things, lol)... - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Modification-on-CollectionsExtensions-tp4692784p4693234.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Tabs
Great job, Ben. Doru On Sun, Jun 9, 2013 at 9:03 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: hello guys :) I would like to introduce a new implementation of tabs with the following features (for now): - tabs with icon (and a label of course) - un-closable tabs - threaded contents loading (with animated icon) - shortcuts handling (to navigate from one tab to the next/previous one, to close a tab) - multi-selection (will display all the selected contents with splitter in between) - actions (each tab can define actions displayed in the tab bar) - Thanks Tudor for the idea - menu items - Thanks Tudor for the idea Here is a little (geeky) video showing a bit of everything: https://dl.dropboxusercontent.com/u/24369478/Tabs.m4v The code can be loaded executing this: Gofer it url: 'http://smalltalkhub.com/mc/BenjaminVanRyseghem/Tabs/main'; package: 'ConfigurationOfTabs'; load. ConfigurationOfTabs loadDefault. TabExample open Next steps: - drag and drop (for rearranging tabs) - Spec support (almost finished) Ben -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] taking a custom screenshot of a submorph
One could, but it is not the same. The inspector offers a quick visual interface that allows you to browse a complex morph hierarchy. Taking the screenshot is secondary, but when combined with the visual feedback it gets more interesting. Cheers, Doru On Sun, Jun 9, 2013 at 7:21 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: One could use the halo, seems faster to me Ben On Jun 6, 2013, at 11:04 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi, Just in case you want to take a screenshot of a submorph, here is a description + video of how you can do it using the GTInspector: http://www.humane-assessment.com/blog/custom-morph-screenshot-with-gtinspector Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Modification on CollectionsExtensions
Thanks again. I committed the change you proposed. So, now we have flatCollect: using writeStream. Cheers, Doru On Tue, Jun 11, 2013 at 3:18 PM, Sebastian Tleye stl...@gmail.com wrote: Hello, Fixing some bugs in Traits we realized that it would be good idea to use CollectionsExtensions package (it has some useful functions), also it would be great to include CollectionsExtensions in Pharo 3.0. One problem we found is that CollectionsExtensions is depending on a Nile Package (that's not a desired feature). In the method CollectionflatCollect: there is a line refering to a nile function nsWriteStream. If i change nsWriteStream for writeStream the dependency disapears. I also run all the tests and they are working, so i was wondering if it would be possible to commit the change. Thanks. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Tabs
As far as I saw, the Tabs are not going through the theme to decide the look and feel. Could we work on this? Perhaps we can take the opportunity to try a new oo-design for the theme code: I proposed to have a theme strategy per morph and have the theme be a conglomerate of these strategies. Cheers, Doru On Fri, Jun 21, 2013 at 12:16 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Thank you :) Ben On Jun 21, 2013, at 6:48 AM, S Krish krishnamachari.sudha...@gmail.com wrote: It is super cool to see Chrome look n feel in Pharo. More so the startup of the video.. Way to go Ben.. It is inspiring On Thu, Jun 20, 2013 at 2:21 PM, Tudor Girba tu...@tudorgirba.com wrote: Great job, Ben. Doru On Sun, Jun 9, 2013 at 9:03 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: hello guys :) I would like to introduce a new implementation of tabs with the following features (for now): - tabs with icon (and a label of course) - un-closable tabs - threaded contents loading (with animated icon) - shortcuts handling (to navigate from one tab to the next/previous one, to close a tab) - multi-selection (will display all the selected contents with splitter in between) - actions (each tab can define actions displayed in the tab bar) - Thanks Tudor for the idea - menu items - Thanks Tudor for the idea Here is a little (geeky) video showing a bit of everything: https://dl.dropboxusercontent.com/u/24369478/Tabs.m4v The code can be loaded executing this: Gofer it url: 'http://smalltalkhub.com/mc/BenjaminVanRyseghem/Tabs/main'; package: 'ConfigurationOfTabs'; load. ConfigurationOfTabs loadDefault. TabExample open Next steps: - drag and drop (for rearranging tabs) - Spec support (almost finished) Ben -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] First shot on acceptance tests for the VM
Excellent! Doru On Fri, Jun 21, 2013 at 5:08 PM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! We were discussing over here about it, so I decided to finally start something on the front of an acceptance test for our VM. The core idea is to stress the VM to test its stability and find bugs and regressions. So I created the ci job in [1] which does: - use latest vm - use 2.0 latest image - loads seaside and moose on it - runs all tests Right now it runs on 6 different slaves, getting different results on each, which we should take care about :). Also there are some things on it that should be improved easily: - once 2.0 summer is released this job should use that version instead of the latest 2.0 - right now we are loading the development version of moose because moose 4.8 is not released (but will be soon :) And of course, now we have them, we can improve them (and make them run because not all of them do :D). Guille [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/ -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] First shot on acceptance tests for the VM
+1 Doru On Sat, Jun 22, 2013 at 9:28 AM, Marcus Denker marcus.den...@inria.frwrote: Very nice! Another thing we need to look at at some point is to make different VM build for each major version. The idea is that there is a dedicated build of the VM for Pharo3, which would be frozen with the release, and then we start with a VM build for Pharo4. I even want them to have the major version number is the binary, so that it is easy to install Pharo3 in Parallel to Pharo4. With this we free ourselves from needed the VM to be at the same time forward *and* backward compatible. And we make sure that the VM that people use for the stable release does not change. Marcus On Jun 21, 2013, at 5:08 PM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! We were discussing over here about it, so I decided to finally start something on the front of an acceptance test for our VM. The core idea is to stress the VM to test its stability and find bugs and regressions. So I created the ci job in [1] which does: - use latest vm - use 2.0 latest image - loads seaside and moose on it - runs all tests Right now it runs on 6 different slaves, getting different results on each, which we should take care about :). Also there are some things on it that should be improved easily: - once 2.0 summer is released this job should use that version instead of the latest 2.0 - right now we are loading the development version of moose because moose 4.8 is not released (but will be soon :) And of course, now we have them, we can improve them (and make them run because not all of them do :D). Guille [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/ -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Object #is:
Actually, a better implementation would be: Objectis: aClassOrSymbol ^ aClassOrSymbol asString = self class name asString Like this you can even pass the class instead of its name (I presume that printOn: will not change any time soon so we can rely on the fact that we can polymorphically obtain the name of the class via asString). Cheers, Doru On Sun, Jun 23, 2013 at 9:30 PM, Camillo Bruni camillobr...@gmail.comwrote: On 2013-06-23, at 21:25, Tudor Girba tu...@tudorgirba.com wrote: If we want to have an Objectis:, why not: Objectis: aSymbol ^ aSymbol = self class name ? Like this, I do not have to override it unless I need to rely on a different mechanism. exactly, that is everybody's immediate reaction, except for the method's author ;).. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Better Interruption in 2.0
Is this integrated in 2.0 already? Doru On Fri, Jun 28, 2013 at 3:12 PM, Goubier Thierry thierry.goub...@cea.frwrote: Hi Stephan, I've put a slice to integrate that and the overall UserInterrupt code to get it to work. Can you try it? It's SLICE-Issue-10569-Backport-20-**Better-Interrruption-**ThierryGoubier.1 in http://ss3.gemtalksystems.com/**ss/PharoInbox/http://ss3.gemtalksystems.com/ss/PharoInbox/ Thierry Le 27/06/2013 00:40, Stephan Eggermont a écrit : Using Henry's processToInterrupt Look for best candidate to interrupt: - any scheduled non-finalization process of lower priority - the weak-finalization process, if scheduled - the UI process Never interrupt the idle process, since killing it is fatal | fallback | fallback := UIManager default uiProcess. Processor scanSchedule: [:p | suspendedContext sender == nil usually means that process is only scheduled but had no chance to run ((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil]) ifTrue: [ p ~~ WeakArray runningFinalizationProcess ifTrue: [^p] ifFalse: [fallback := p]] ] startingAt: Processor activePriority. ^fallback in todays Moose 4.8 (on Pharo 20608) on the april 10 VM allows for better interruption, up to the point where the system runs out of memory without a lowspace warning after I assume trying to collect garbage for 20 minutes or so. Stephan -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] WhatsUp from: 2013-07-01 until: 2013-07-14
On Mon, Jul 1, 2013 at 7:00 AM, seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: Preparing for Moose 4.8 release Working with Andrei on fancy, yet cheap debuggers ### What's next, until 2013-07-14 (*): Release Moose 4.8 Move Moose development on Pharo 3.0 Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] Fwd: [Pharo-users] Tudor Girba joins Pharo Board
I forgot again to push the reply all button. Doru -- Forwarded message -- From: Tudor Girba tu...@tudorgirba.com Date: Wed, Jul 3, 2013 at 9:59 AM Subject: Re: [Pharo-users] [Pharo-dev] Tudor Girba joins Pharo Board To: Any question about pharo is welcome pharo-us...@lists.pharo.org Hi everyone, Thanks for the wishes. Just a note: I do not see getting in the board as a prize, but as a work to do. And there is some work left :) One of the points that I will stress everyone with is the marketing of Pharo. Marketing, like any other meaningful thing, requires design. Design requires feedback. And feedback requires time. That is why we have to start with this endeavor sooner rather than later. The other thing about marketing is that it can actually be meaningful, but this happens only when we live what we sell. Pharo does offer a fantastic opportunity because when people talk about it, their eyes blink. This reveals both value and values that are packaged deep in Pharo. We just have to capitalize on that, and I want to start by making explicit what makes Pharo unique and valuable. Everyone thinks of various things, but we do not yet have a concerted message. This message, and I will aim at one single message, has to transpire in everything we do: from the way we design the code, to the concepts we adopt in the language, to the frameworks we build on top, and to the developer and user experience. This is exciting, but it requires team effort. This is where you come in. We want your energy outside of pure coding. More concrete proposals will come in the near future, but until then, feel free to chip in your ideas. Cheers, Doru On Wed, Jul 3, 2013 at 4:16 AM, Mariano Martinez Peck marianop...@gmail.com wrote: Congrats! Doru, It's well deserved. Best, On Tue, Jul 2, 2013 at 7:51 PM, Alexandre Bergel alexandre.ber...@me.comwrote: Cool! Alexandre On Jul 2, 2013, at 10:12 AM, Sven Van Caekenberghe s...@stfx.eu wrote: Hi, The Pharo Board is pleased to announce that Tudor Girba has recently joined the Pharo Board. Among others, he will try to contribute on long term issues like the positioning of Pharo. Stéphane, Marcus Sven http://www.pharo-project.org/about/board -- http://pharo.org http://association.pharo.org http://consortium.pharo.org -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Mariano http://marianopeck.wordpress.com -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] We did it! SlotClassBuilder is active
Wow! I cannot wait to clunky dictionary-based instance variable extensions with slots. Doru On Wed, Jul 3, 2013 at 5:00 PM, Marcus Denker marcus.den...@inria.frwrote: Hi, Today we turned on the SlotClassBuilder… this means actually quite a huge change, as it puts into place lots of things that we can build on later. What it means for now - A new, much easier to understand ClassBuilder - meta Objects. Layouts + Slots For example, there is now for every instance variable a meta object that describes it It will be very interesting to see what we can do with that! Thanks to Toon + Camillo for the original implementation, and Martin Dias with Camillo for the work to get in really into 3.0. Marcus -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] We did it! SlotClassBuilder is active
I forgot about this side-effect. PetitParser will be so happy. Doru On Thu, Jul 4, 2013 at 9:51 AM, Norbert Hartl norb...@hartl.name wrote: Hehe, yes, and finally I can have more than 254 instance variables! Norbert Am 03.07.2013 um 23:38 schrieb Tudor Girba tu...@tudorgirba.com: Wow! I cannot wait to clunky dictionary-based instance variable extensions with slots. Doru On Wed, Jul 3, 2013 at 5:00 PM, Marcus Denker marcus.den...@inria.frwrote: Hi, Today we turned on the SlotClassBuilder… this means actually quite a huge change, as it puts into place lots of things that we can build on later. What it means for now - A new, much easier to understand ClassBuilder - meta Objects. Layouts + Slots For example, there is now for every instance variable a meta object that describes it It will be very interesting to see what we can do with that! Thanks to Toon + Camillo for the original implementation, and Martin Dias with Camillo for the work to get in really into 3.0. Marcus -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] We did it! SlotClassBuilder is active
And Moose :) Doru On Thu, Jul 4, 2013 at 10:56 AM, Stephan Eggermont step...@stack.nl wrote: Great! Time to simplify Magritte. Stephan -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Moose-dev] SourceCity works
+1 Doru On Jul 4, 2013, at 6:23 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi Erwan and all, Just to make a few things clear about Roassal 3d vs SourceCity. We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene. Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal). Our objective is to offer a great 3d framework to make a truly flying SourceCity. Does this make sense to you? Cheers, Alexandre On Jul 4, 2013, at 10:47 AM, Erwan Douaille douailleer...@gmail.com wrote: https://ci.inria.fr/pharo-contribution/job/SourceCity/ done 2013/7/4 Camillo Bruni camillobr...@gmail.com On 2013-07-04, at 15:35, Erwan Douaille douailleer...@gmail.com wrote: I updated the ConfigurationOfSourceCity. Gofer new smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; configuration; load. ConfigurationOfSourceCity loadBleedingEdge would it make sense to make a jenkins job for this? -- Best regards, Douaille Erwan douaille.er...@gmail.com -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Live like you mean it.
Re: [Pharo-dev] Sunburst visualization
This looks like really a fantastic job. I cannot wait to see the code :) Doru On Jul 4, 2013, at 3:20 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! We are currently working on a Sunburst based on top of Roassal. Milton is doing a fantastic job! Here some early screenshots: image copy 2.pngimage copy.pngimage.png Milton Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com If you can't say why something is relevant, it probably isn't.
Re: [Pharo-dev] sunit failures vs errors
Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error). Please do not do away with this distinction. Cheers, Doru On Jul 10, 2013, at 10:34 AM, Damien Cassou damien.cas...@gmail.com wrote: On Wed, Jul 10, 2013 at 8:16 AM, Norbert Hartl norb...@hartl.name wrote: I use them. I always fix the red tests first because they are mostly easier to fix and some of them lead to yellow tests I agree with you. I tend to do that as well. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- www.tudorgirba.com Beauty is where we see it.
Re: [Pharo-dev] sunit failures vs errors
Hi, On Jul 10, 2013, at 1:47 PM, Camillo Bruni camillobr...@gmail.com wrote: On 2013-07-10, at 13:32, Tudor Girba tu...@tudorgirba.com wrote: Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error). In which sense? In the sense that they express two distinct classes of problems. As a programmer I have to tackle them both the same way: start debugging. Yes, but not all debugging is created equal :) I really do not see the difference. In both cases the code does not behave as expected. One might even say that there is a global contract that the code does not raise exceptions. Yes, but then what is the point of explicit assertions? :) Tackling the failures first is purely a habit induced by the existing system that errors are worse than failures Actually, it is the other way around :). Errors are much faster to fix than failures. Errors are often caused by bad initializations and you can see it rather fast when you see the exceptions. On the other hand, failures are often more sensitive to the deep semantics of your code and that is why they require more time to get fixed. Cheers, Doru -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-dev] Athens + Amber progress
Hi, Great work! Also, Matthias is describing the progress on a dedicated blog, so people can stay tuned: http://amber-athens.m-sp.org/ Cheers, Doru On Jul 12, 2013, at 5:51 PM, Igor Stasenko siguc...@gmail.com wrote: Hi, i just wanna share news about progress on subject GSoC project. Matthew made quite decent progress on the subject. It is almost there, just some glitches here and there, but in overall, i am quite happy, and i think it is already in quite useful state. To check it, just follow the link on your browser: http://matthias-springer.github.io/amber-athens/ (works best with chrome then firefox) For impatient: go to step 2, press doit, then skip to step 32 and press doit again :) -- Best regards, Igor Stasenko. -- www.tudorgirba.com What we can governs what we wish.
Re: [Pharo-dev] Some Spec questions
Exciting times :) Doru On Jul 13, 2013, at 8:08 AM, Clément Bera bera.clem...@gmail.com wrote: Ok, then we will integrate it together when you come to Lille in 2 weeks. Good news. Cheers, 2013/7/12 Andrei Vasile Chis chisvasileand...@gmail.com Hi Clément, Hi Clara, What about integrating the new debugger by default now ? I mean the new debugger is now in Pharo 3.0 alpha but the old debugger is still triggered by default, for example when you do Cmd+Maj+d or when you set the setting 'Always open full debugger'. We (Marcus and I) would like to integrate it now by default in Pharo 3.0 alpha, so we have enough time to stabilize it (in case of problems) and we can then remove the old debugger and old inspectors from Pharo. Now I want your point of view: - What do you think about integrating the spec debugger by default next week ? In two weeks (22 July) I would visit you in Lille. That would be a good time to integrate. - Is it currently stable enough ? All the features that are present at the moment are quite stable. - Should I wait a little more so you can add extra features ? I've talked with Andrei and we've set a milestone. By next week, we would like to have done issues 10956 10952 10954 10953 10955 If at least the first three issues are done, then the new debugger will have most of the necessary features. I'd also help with these and I hope we'll be done by the end of this month. By next week I will have more time, since the semester will be finished. Having Andrei's debugger by default requires that it has the full stack menu ready before the Pharo 3.0 release (next spring), because if not people will blame all the Pharo team. - Are you working on it ? That's what I plan to do next week :) I'm working on it, but not full time. - Will it be ready before the next Pharo release ? If you think you need to improve the debugger before we integrate it by default, for example with Clara's GSoC work, please tell me when it will be ready so we can add it into the Pharo 3.0 integration planning. Then I guess you can add a slice with your improvements in the Pharo bug tracker, and I will add an extra slice with smalltalk tools change so the new debugger will be triggered by default. It would be nice if we can integrate it before the end of september. We'll surely be able to have all the missing features by the end of September. They do not require so much work. In any case I will be in case with both Andrei and you (if you don't mind) to get this done... Please do :) Cheers, Andrei -- www.tudorgirba.com Problem solving efficiency grows with the abstractness level of problem understanding.
Re: [Pharo-dev] [2.0] Issues tagged for Pharo 2
I would definitely say so :) Doru On Tue, Jul 16, 2013 at 9:21 AM, Marcus Denker marcus.den...@inria.frwrote: Hi, There are 7 issues tagged for Pharo2: https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed None of them was important enough to be fixed (or even discussed on this list). So I guess we can conclude that they are not showstoppers to be fixed for Pharo2? Marcus -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] modeling Zinc request method
Hi, The recently announced cool tutorial on using Zinc made me read the Zinc code in a bit more detail. I must admit, it makes for a nice read. In the process, I stumbled across: knownHTTPMethods ^ #( Standard HTTP 1.1 Verbs GET PUT POST DELETE HEAD TRACE OPTIONS CONNECT PATCH WebDAV verbs PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK) I would propose to model these as classes (inheriting from ZnRequestMethod). If we would have such a hierarchy, then the following code: ZnSingleThreadedServerhandleRequest: request ... request method = #HEAD ifTrue: [ response clearEntity ]. Could become something like: ZnSingleThreadedServerhandleRequest: request ... request method clearEntityForSingleThreadedServerResponse: response ZnRequestMethodclearEntityForSingleThreadedServer: aResponse nothing ZnHeadRequestMethodclearEntityForSingleThreadedServer: aResponse aResponse clearEntity What do you think? Cheers, Doru -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done.
Re: [Pharo-dev] Spec delete method
I guess what Stef means is that he would like to know if there is a way specify custom behavior when a window closes, and then use this for his purpose of unregistering from some announcer. Cheers, Doru On Wed, Jul 17, 2013 at 2:36 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I do not think it's a UI framework concern to handle model behaviour (like registration to announcement) Ben On Jul 17, 2013, at 9:40 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi ben I would like to unsubscribe announcement when the window is closed. Is there a hook for that in Spec? Stef -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [update 3.0] #30285
Hi, On Fri, Jul 19, 2013 at 2:27 PM, Marcus Denker marcus.den...@inria.frwrote: 30285 - 10823 Kill old list model https://pharo.fogbugz.com/f/cases/10823 11136 RadioButtonGroupExample new openWithSpec is not working https://pharo.fogbugz.com/f/cases/11136 11174 Add support for sync position of multiple widgets with just one scroll bar https://pharo.fogbugz.com/f/cases/11174 How does this work? Do you have an example at hand? Doru Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.33.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenker.859.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.48.diff -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About abuse of inheritance
Thanks, Hannes. I am not completely misunderstood, then :) Doru On Sat, Jul 20, 2013 at 2:02 PM, H. Hirzel hannes.hir...@gmail.com wrote: On 7/19/13, Igor Stasenko siguc...@gmail.com wrote: On 19 July 2013 16:17, Tudor Girba tu...@tudorgirba.com wrote: Hi Igor, I love these discussions. I agree that abusing inheritance is counter-productive. Definitely, Shampoo subclass: #Shower does not match any mental model I can think of. But, I am not seeing Announcer subclass: #MyDomainConcept equally as an abuse. Here is why. When I say Object subclass: #MyDomainConcept, my actual intention is not to reuse types necessarily, but rather the infrastructure needed for the Smalltalk runtime. From this point of view, it is an implementation inheritance. I could as well, inherit from ProtoObject, but I do not do it because Object gives me a bit more technical infrastructure. For me, Announcer is nothing but an Object that has an extra technical capability. Inheriting from Announcer rather than Object seems the same as inheriting from Object rather than ProtoObject. Now, you can shoot. As i understood, you see nothing wrong in using inheritance as reuse, while i do. not generally I assume Tudor thinks, only for this particular case of sub classing Announcer. Announcing behaviour may be considered part of a package objects should have and this has been the case in Smalltalk since the beginning, though implemented with the symbol based changed/update mechanism. To restate Yes, I agree that subclasses should specialize the behaviour of the superclass. But there need to be classes first you may subclass to specialize and these inherit general properties of object behaviour. --Hannes The argument with Object does not stands, to my thinking, because it is most generic class, and protocols it implements used by various parts of a system, including reflection etc, and those parts actually expecting that all objects they dealing with is at least implementing Object protocol(s). So, strictly speaking by inheriting from Object you may call it reuse, but to my thinking it is more about having a guarantee that your class will play well with the rest of smalltalk ecosystem (even if it's not your direct concern). While in case of inheriting from Announcer it is something different: you already have specific behavior which is non-universal for all objects in system (otherwise why not implementing Announcer protocol in Object?). Also, i am sure you aware, that by doing this, you introducing a certain degree of rigidness in your model (every time you refer directly to names instead of protocols, little kittie dies ;) because if today, Announcer serves well for your needs, and all is happy.. but maybe tomorrow, one guy will make a better one AnnouncerOnSteroids.. and to reuse it , you will need to change the parent in all numerous classes where you used Announcer originally. And to make it absolutely ridiculous, imagine how you will give user a choice whether use one Announcer or AnnouncerOnSteroids? You will recompile your classes each time? And what if parts of your model insist on using just Announcer while others having no problem with trying to play with AnnouncerOnSteroids? Another aspect of such abuse is when you inherit, you are tempted to use direct access to internal state and private methods, and that leads to really strange and complex problems later.. Just giving you an example: Suppose we have a class Butter, which implements #numberOfCalories and #fatPercentage protocols.. Now we do it like that: Butter subclass: #Fridge and then, of course fridge := Fridge new. fridge fatPercentage or: fridge fatPercentage: 10. ^^^ just look at the above line, how much sense you think this piece of code makes for reader, who will try to reason what is happens in your code? And why you think it is not the same story with Announcer? Because by subclassing from it, you expose its protocol(s) in places where it is not needed and will cause problems and confusion. Because when you inherit to reuse, not to specialize, then users of such class in most cases won't use full protocol of the superclass, nor require it.. and therefore by providing more than necessary, you are basically violating the principle of least authority. To fix that, you will need to override certain methods in your subclass to prevent exposing unwanted/low-level behavior to users. But that's again wrong, because then your model now starting to know too much about Announcer's internals, which should be an implementation detail, and adds even more rigidness to your design. -- Best regards, Igor Stasenko. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About abuse of inheritance
Certainly :) Doru On Sat, Jul 20, 2013 at 1:48 PM, Camillo Bruni camillobr...@gmail.comwrote: How about statefull Traits? http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf On 2013-07-20, at 12:48, Denis Kudriashov dionisi...@gmail.com wrote: Hi 2013/7/19 Igor Stasenko siguc...@gmail.com So, on your place, if you really need a lot of classes with announcer capabilities, you can do it like that: Object subclass: #ObjectWithAnnouncer instvars: 'announcer' ObjectWithAnnouncer is exactly what I think about Announcer. I just need class which makes my objects events sources. And I'm wondering why Announcer is bad for this? Just look at Announcer definition: Object subclass: #Announcer instanceVariableNames: 'registry' classVariableNames: '' poolDictionaries: '' category: 'Announcements-Core' registry variable is instance of SubscriptionsRegistry which actually implements all announcements logic. Announcer just adds convenient public api to events subscriptions and delivering. No complex logic. No actual knowledge about how announcements work. And your argument why you subclass from Announcer looks to me like why you subclass from SubscriptionsRegistry. But I'm not. Nobody doing it. So i'm not understand why you want another wrapper around Announcer. (To me subscriptions is better name then registry. And I prefer composition than inheritance too). then may implement same protocol as in Announcer in it, which will simply delegate to announcer ivar. And i bet, you don't want to expose full Announcer protocol there, while probably you may want to implement some convenience protocols, which Announcer lacking. So, at the end by subclassing from ObjectWithAnnouncer you will be reusing its capabilities in each and every subclass of it, but by delegating real job, you are free from worrying about dealing with implementation detail and exposing unwanted state/protocols to its users. Another aspect of it, is when i see: ObjectWithAnnouncer subclass: #MyDomainObject it tells me, aha.. so some (at least this one) of his domain objects having announcers, and the valid protocols is defined in ObjectWithAnnouncer. but when i see Announcer subclass: #MyDomainObject i starting to be uncertain: is Announcer private there or public? can i send messages like #basicSubscribe: to your domain object and expect that it will be handled correctly? Or do i allowed to subscribe directly at all, because maybe domain object has some specific protocol(s) and ways to do that.. Every such question and uncertainty for coder means more time, more errors, and less productivity. -- Best regards, Igor Stasenko. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About abuse of inheritance
I love this debate, but given the energy it attracted, I now apologize to have fueled it. By reading the thread, I believe that everyone involved in the discussion is on the same page on 99.9% of the cases, the only real difference being the case of the Announcer (and even there, the difference is more philosophical in nature). Would it be Ok to call it a day and move on? :) Cheers, Doru On Mon, Jul 22, 2013 at 1:05 PM, Igor Stasenko siguc...@gmail.com wrote: On 21 July 2013 20:21, Denis Kudriashov dionisi...@gmail.com wrote: 2013/7/21 Stéphane Ducasse stephane.duca...@inria.fr Interesting how many people in this list think that Announcer subclass: #TxEditor provides special implementation of announcer named TxEditor? Many this is composition using inheritance and inheritance should not be used like that. Announcer subclass: #GreedyAnnouncer Announcer subclass: #RemoteAnnouncer And if we prefer composition we should not implement such kind of hierarchy. We should implement GreadySubscriptionsRegistry, RemoteSubscriptionsRegistry or AsynchSubscriptionsRegistry and reuse existed Announcer. All subscribing and delivering logic implemented by subscription registry. Announcer is just simple delegator with convenient api to create Subscription instances: Announcersubscribe: anAnnouncementClass do: aValuable Declare that when anAnnouncementClass is raised, aValuable is executed. ^ registry add: ( AnnouncementSubscription new announcer: self; announcementClass: anAnnouncementClass; valuable: aValuable) Announcerannounce: anAnnouncement | announcement | announcement := anAnnouncement asAnnouncement. registry ifNotNil: [ registry deliver: announcement ]. ^ announcement All magic happens inside #add: and #deliver: methods of SubscriptionsRegistry. Also announcements framework provides very nice feature: you can have announcer as last argument of event handler selector (that's why AnnouncementSubscription contains reference to announcer instance): announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: aSubscriber Without subclassing YourEventsSource from Announcer you will not have such feature. Or you will need implement complex subscription method inside YourEventSource which will delegates special event handler to its announcer 1. you don't need separate class to represent event source. it can be any object which does: announcer announce: Foo. in any place.. I do not see any practical gains from forming a separate class for this role. It is barely formalizeable because the way how users creating and triggering events is arbitrary. 2. SubscriptionRegistry is an implementation detail. It is private. It is a way how Announcer doing things inside. It should be no concern of anything outside to consider what it does. You won't find this class in VisualWorks implementation, for instance. 3. again, event source - is any object which says 'announcer announce: ...' It is NOT announcer, because announcer is an event dispatcher. dispatcher ~= source Is it so hard to see a difference? When you subclass from Announcer, is that you want to say: 'self announce:' , so the very same object acts both as event source and event dispatcher. But then , as Stef said, by subclassing you inheriting API. So, what prevents me from writing following code, in my own class, which uses your domain object in a following way: coolDomainObject := YourDomainObjectWhichInheritsFromAnnouncer new. coolDomainObject on: Foo do: #bar. coolDomainObject announce: Foo. That i guess is not something you expected, huh? But why not? As long as your object understand this protocol, and as long as you don't overriding original behavior of Announcer, i can abuse your object in a way you did not expected. And this is a consequence of violating principle of least authority. Because once you declare that we're free to use subclassing for any purpose, then, i can declare: i am free to use any subclass of Announcer as announcer for myself. Lets write random code, do not follow any rules and everyone will be happy. --- Best regards, Igor Stasenko. -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [ann] snapshotcello
Hi, Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot' You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-ready You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Cheers, Doru -- www.tudorgirba.com Every successful trip needs a suitable vehicle.
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: [ann] snapshotcello
Hi, On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs dale.henri...@gemtalksystems.com wrote: Stef, I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). What is not clear? I would be interested in describing our scenario in more details because I think this is a development pattern. But, I need some concrete questions to start from. However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. I still do not understand why Versionner would be affected by the current versions given that we are only generating versions that should be immutable hence no need for management. With that said it _is_ performing a useful function ... I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this approved approach when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... Having a different way to store the information should be no problem. I am curious about your ideas. Cheers, Doru Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Moose-related development moose-...@iam.unibe.ch | Cc: Any question about pharo is welcome pharo-us...@lists.pharo.org, Pharo Development List | pharo-dev@lists.pharo.org | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba tu...@tudorgirba.com | wrote: | | Hi, | | Stef and I developed Snapshotcello, a little utility that enables | you to freeze a snapshot of a given configuration based on what is | already loaded in your current image. | | The idea is simple. You develop against the latest versions of all | packages, and commit your changes for each package. When you are | ready for a release, you assemble your image, and generate a | snapshot version that can be reloaded later. | | Here is an example of how it can work to take a snapshot of a | development version: | Snapshotcello new | configurationClass: ConfigurationOfMoose; | configurationVersion: #development; | publishVersion: '4.8-snapshot' | | You can find more details here: | http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-ready | | You can get the code at: | Gofer new | smalltalkhubUser: 'girba' project: 'Snapshotcello'; | package: 'ConfigurationOfSnapshotcello'; | load. | (Smalltalk globals at: #ConfigurationOfSnapshotcello) | loadDevelopment | | Cheers, | Doru | | -- | www.tudorgirba.com | | Every successful trip needs a suitable vehicle. | | | | | | ___ | Moose-dev mailing list | moose-...@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | ___ | Moose-dev mailing list | moose-...@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | -- www.tudorgirba.com Live like you mean it.
Re: [Pharo-dev] [Moose-dev] [ann] snapshotcello
Hi, On Jul 24, 2013, at 8:49 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Jul 24, 2013, at 12:09 AM, Camillo Bruni camillobr...@gmail.com wrote: Nice :) Random Question: Do you have a way to file out a whole configuration as a fuel file? Do you mean the packages? or the configuration itself? What snapshotcello does is that it walks the configurations and gather the packages and their repository and generate a list. I think he means all packages. I like the idea. or would it be considerably easier to so with your Snappy tool? probably because you get a linear list of packages. It actually does not depend that much on Snapshotcello, given that Snapshotcello actually uses Metacello for anything meaningful. But, it could be cheaper to simply traverse the snapshotted list of packages and dump them in fuel. Cheers, Doru Stef On 2013-07-23, at 23:17, Stéphane Ducasse stephane.duca...@inria.fr wrote: Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. Because everybody may need this cool feature. Stef On Jul 23, 2013, at 10:43 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi, Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot' You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-ready You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Cheers, Doru -- www.tudorgirba.com Every successful trip needs a suitable vehicle. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com No matter how many recipes we know, we still value a chef.
Re: [Pharo-dev] Loading scripts vs. configs with #stable and config browser (was: [ann] snapshotcello)
Hi Torsten, Thanks for the rant :) It did not put it as a release yet, because I still wanted people to play with it. Hence the suggested loadDevelopment. As for Moose not being in the configuration browser, it is precisely because we could not really release it until now in a reliable fashion that you do not find it there :). Snapshotcello is a little tool to help us bootstrap precisely around this problem. Cheers, Doru On Wed, Jul 24, 2013 at 10:04 AM, Torsten Bergmann asta...@gmx.de wrote: Tudor wrote: You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Sorry about the rant in advance (which is more general and not only specific to snapshotcello), but: Next time someone wants this (or another) nice little Pharo tool: - one has to remember this load script or have to find the announcement mail again - one has to a lot of typing the expression or copying to a workspace to load it. Just with the posted load script he does dont know if Pharo 1.4, 2.0 or 3.0 was used to develop it, so how does he know the Pharo version to use it without failures? A pharo version where it is not broken. Maybe the user is still using Pharo 2.0 but maybe the tool requires at least Pharo 3.0 ... What about a new user who starts tomorrow with Pharo and never read this announcement. Since he entered the mailinglist very late he missed the mail with the script. How can he now about this super cool package? Why cant it be more accessible? I propose: PLEASE define a #stable for the working versions and place an additional copy in: - ss3.gemtalksystems.com/ss/MetaRepoForPharo20 (Pharo 2.0) or - http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main; (Pharo 3.0) when you know it runs in the according pharo version. It will then appear in the config browser. If it is not in the config browser of the current pharo version for easy loading then it does not really exist. ;) It only exists for the people who read about it in the mailinglist. Think of a first time user who downloads Pharo 2.0. He may never stumble over the load script or the tool in Smalltalkhub. I know: it may not yet be the best mechanism to provide packages to users (we need more infos on the configs, hence catalog and automatic verification in the future) - but still it is better than the load scripts and possible confusion. So please CARE ABOUT YOUR USERS and make your packages available like this so it can be easily accessible and loadable right from the according image! Same for Roassal, Moose, ... and all the nice packages that now appear in the Pharo universe... Thanks T. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello
Perhaps I missed something in the toolbox, but as far as I know you cannot create a version of a configuration that is composed of multiple sub-projects nested multiple levels deep. Could you describe the way you are using the Metacello Toolbox? Doru On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau jo...@inceptive.be wrote: Hi Doru, Stef, May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe. Cheers! Johan On 24 Jul 2013, at 09:52, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Jul 24, 2013, at 9:11 AM, Tudor Girba tu...@tudorgirba.com wrote: Hi, On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs dale.henri...@gemtalksystems.com wrote: Stef, I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work. I do not understand this point. What do you mean by interpreting the configuration trees? I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations. Doru With that said it _is_ performing a useful function ... I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this approved approach when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Moose-related development moose-...@iam.unibe.ch | Cc: Any question about pharo is welcome pharo-us...@lists.pharo.org, Pharo Development List | pharo-dev@lists.pharo.org | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba tu...@tudorgirba.com | wrote: | | Hi, | | Stef and I developed Snapshotcello, a little utility that enables | you to freeze a snapshot of a given configuration based on what is | already loaded in your current image. | | The idea is simple. You develop against the latest versions of all | packages, and commit your changes for each package. When you are | ready for a release, you assemble your image, and generate a | snapshot version that can be reloaded later. | | Here is an example of how it can work to take a snapshot of a | development version: | Snapshotcello new | configurationClass: ConfigurationOfMoose; | configurationVersion: #development; | publishVersion: '4.8-snapshot' | | You can find more details here: | http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-ready | | You can get the code at: | Gofer new | smalltalkhubUser: 'girba' project: 'Snapshotcello'; | package: 'ConfigurationOfSnapshotcello'; | load. | (Smalltalk globals at: #ConfigurationOfSnapshotcello) | loadDevelopment | | Cheers, | Doru | | -- | www.tudorgirba.com | | Every successful trip needs a suitable vehicle. | | | | | | ___ | Moose-dev mailing list | moose-...@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | ___ | Moose-dev mailing list | moose-...@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com From an abstract enough point of view, any two things are similar. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [update 3.0] #30295
Hi, On Wed, Jul 24, 2013 at 1:05 PM, Marcus Denker marcus.den...@inria.frwrote: 30295 - 11219 Speed up test run: #testAddMetaclassPattern in RBRefactoringChangeTests https://pharo.fogbugz.com/f/cases/11219 11224 Enable the new debugger https://pharo.fogbugz.com/f/cases/11224 This is so cool! :) Doru 10780 Inspecting self in SpecDebugger inspects nil https://pharo.fogbugz.com/f/cases/10780 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.99.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Changes-MarcusDenker.26.diff -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello
Hi, I would be happy to blend Snapshotcello into Metacello. Cheers, Doru On Jul 24, 2013, at 9:05 PM, Dale K. Henrichs dale.henri...@gemtalksystems.com wrote: - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Pharo Development List pharo-dev@lists.pharo.org | Cc: Moose-related development moose-...@iam.unibe.ch, Any question about pharo is welcome | pharo-us...@lists.pharo.org | Sent: Tuesday, July 23, 2013 11:48:27 PM | Subject: Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello | | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Stef, | | I haven't completely wrapped my brain around what SnapshotCello | does so I don't have an informed opinion ... the fact that you | found a need to invent SnapshotCello does speak volumes to the | fact that there is a need that is going unmet:). | | However, I don't like the fact that you end up sending a non-spec | message to make this work (#populateSpec:with:). Tools like | Versioner will not be able to rewrite a method like this correctly | so it is a less than satisfactory workaround to the method literal | limit. | | Indeed. May be in the future we could recreate a simple compliant | spec driven method by interpreting the | existing configuration trees but this requires some work. Absolutely and it would be work that I'd be willing to do ... From that perspective SnapshotCello is a very good spec for what you and the Moose team need. Dale -- www.tudorgirba.com Every thing has its own flow.
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello
Unfortunately, I will not be able to join :( Doru On Wed, Jul 24, 2013 at 9:38 PM, Dale K. Henrichs dale.henri...@gemtalksystems.com wrote: Doru, Are you going to be at ESUG this year? I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ... I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of automatic transitive versioning of all nested configurations is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient... Dale - Original Message - | From: Tudor Girba tu...@tudorgirba.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau jo...@inceptive.be | wrote: | | Doru, | | What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | Perhaps this is the difference I did not immediately extract from | your description. Re-reading it with this focus makes the | difference clear I think. | | My use of the toolbox is indeed to generate or update a version for | a single project where all 'nested' projects are referenced by | project version. As I understand it, the snapshot version is a | 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | I think I get it now. thanks | | Johan | | On 24 Jul 2013, at 12:45, Tudor Girba tu...@tudorgirba.com wrote: | | Perhaps I missed something in the toolbox, but as far as I know | you cannot create a version of a configuration that is composed | of multiple sub-projects nested multiple levels deep. | | Could you describe the way you are using the Metacello Toolbox? | | Doru | | | On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | jo...@inceptive.be wrote: | Hi Doru, Stef, | | May I ask what the difference is with the version generation and | updating methods found in MetacelloToolbox ? I want to | understand, because I am currently using these of | MetacelloToolbox to do the things you describe. | | Cheers! | Johan | | On 24 Jul 2013, at 09:52, Stéphane Ducasse | stephane.duca...@inria.fr wrote: | | | On Jul 24, 2013, at 9:11 AM, Tudor Girba tu...@tudorgirba.com | wrote: | | Hi, | | On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | stephane.duca...@inria.fr wrote: | | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Stef, | | I haven't completely wrapped my brain around what | SnapshotCello does so I don't have an informed opinion ... | the fact that you found a need to invent SnapshotCello does | speak volumes to the fact that there is a need that is going | unmet:). | | However, I don't like the fact that you end up sending a | non-spec message to make this work (#populateSpec:with:). | Tools like Versioner will not be able to rewrite a method | like this correctly so it is a less than satisfactory | workaround to the method literal limit. | Indeed. May be in the future we could recreate a simple | compliant spec driven method by interpreting the | existing configuration trees but this requires some work. | | I do not understand this point. What do you mean by | interpreting the configuration trees? | | I mean going over the configurations with dependencies to | recreate
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello
This would be so cool :). Doru On Thu, Jul 25, 2013 at 8:47 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi dale do you plan to write a visitor on metacello spec? Stef On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs dale.henri...@gemtalksystems.com wrote: Doru, Are you going to be at ESUG this year? I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ... I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of automatic transitive versioning of all nested configurations is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient... Dale - Original Message - | From: Tudor Girba tu...@tudorgirba.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau jo...@inceptive.be | wrote: | | Doru, | | What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | Perhaps this is the difference I did not immediately extract from | your description. Re-reading it with this focus makes the | difference clear I think. | | My use of the toolbox is indeed to generate or update a version for | a single project where all 'nested' projects are referenced by | project version. As I understand it, the snapshot version is a | 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | I think I get it now. thanks | | Johan | | On 24 Jul 2013, at 12:45, Tudor Girba tu...@tudorgirba.com wrote: | | Perhaps I missed something in the toolbox, but as far as I know | you cannot create a version of a configuration that is composed | of multiple sub-projects nested multiple levels deep. | | Could you describe the way you are using the Metacello Toolbox? | | Doru | | | On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | jo...@inceptive.be wrote: | Hi Doru, Stef, | | May I ask what the difference is with the version generation and | updating methods found in MetacelloToolbox ? I want to | understand, because I am currently using these of | MetacelloToolbox to do the things you describe. | | Cheers! | Johan | | On 24 Jul 2013, at 09:52, Stéphane Ducasse | stephane.duca...@inria.fr wrote: | | | On Jul 24, 2013, at 9:11 AM, Tudor Girba tu...@tudorgirba.com | wrote: | | Hi, | | On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | stephane.duca...@inria.fr wrote: | | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Stef, | | I haven't completely wrapped my brain around what | SnapshotCello does so I don't have an informed opinion ... | the fact that you found a need to invent SnapshotCello does | speak volumes to the fact that there is a need that is going | unmet:). | | However, I don't like the fact that you end up sending a | non-spec message to make this work (#populateSpec:with:). | Tools like Versioner will not be able to rewrite a method | like this correctly so it is a less than satisfactory | workaround to the method literal limit. | Indeed. May be in the future we could recreate a simple | compliant spec driven method
Re: [Pharo-dev] Loading scripts vs. configs with #stable and config browser (was: [ann] snapshotcello)
Snapshotcello is now in ss3.gemtalksystems.com/ss/MetaRepoForPharo20. Once it will be tested in Pharo 3.0, it will be published in there, too. Doru On Wed, Jul 24, 2013 at 12:42 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Torsten, Thanks for the rant :) It did not put it as a release yet, because I still wanted people to play with it. Hence the suggested loadDevelopment. As for Moose not being in the configuration browser, it is precisely because we could not really release it until now in a reliable fashion that you do not find it there :). Snapshotcello is a little tool to help us bootstrap precisely around this problem. Cheers, Doru On Wed, Jul 24, 2013 at 10:04 AM, Torsten Bergmann asta...@gmx.de wrote: Tudor wrote: You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Sorry about the rant in advance (which is more general and not only specific to snapshotcello), but: Next time someone wants this (or another) nice little Pharo tool: - one has to remember this load script or have to find the announcement mail again - one has to a lot of typing the expression or copying to a workspace to load it. Just with the posted load script he does dont know if Pharo 1.4, 2.0 or 3.0 was used to develop it, so how does he know the Pharo version to use it without failures? A pharo version where it is not broken. Maybe the user is still using Pharo 2.0 but maybe the tool requires at least Pharo 3.0 ... What about a new user who starts tomorrow with Pharo and never read this announcement. Since he entered the mailinglist very late he missed the mail with the script. How can he now about this super cool package? Why cant it be more accessible? I propose: PLEASE define a #stable for the working versions and place an additional copy in: - ss3.gemtalksystems.com/ss/MetaRepoForPharo20 (Pharo 2.0) or - http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main; (Pharo 3.0) when you know it runs in the according pharo version. It will then appear in the config browser. If it is not in the config browser of the current pharo version for easy loading then it does not really exist. ;) It only exists for the people who read about it in the mailinglist. Think of a first time user who downloads Pharo 2.0. He may never stumble over the load script or the tool in Smalltalkhub. I know: it may not yet be the best mechanism to provide packages to users (we need more infos on the configs, hence catalog and automatic verification in the future) - but still it is better than the load scripts and possible confusion. So please CARE ABOUT YOUR USERS and make your packages available like this so it can be easily accessible and loadable right from the according image! Same for Roassal, Moose, ... and all the nice packages that now appear in the Pharo universe... Thanks T. -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] moose build - pharo vm crash
Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Checking your Gravatar
Ha. Funny. I actually did not know about Alt+Shift+Click :). I only know the Ctrl+Shift+Click combination to spawn the menu and choose halos from there. Doru On Tue, Aug 13, 2013 at 11:04 PM, Mariano Martinez Peck marianop...@gmail.com wrote: okit's alt (option) + command + shift in my keyword... you were lucky Doru :) On Tue, Aug 13, 2013 at 6:01 PM, Mariano Martinez Peck marianop...@gmail.com wrote: I forgot to say..cmd+shift+click doesn't open the halos for me, it just picks the picture and draws a small shadow and allows me to move the picture around... bug? On Tue, Aug 13, 2013 at 6:00 PM, Mariano Martinez Peck marianop...@gmail.com wrote: That's so cool Doru :) I arrived at the point of ImageMorph allInstances size. The World submorphs select: [:each | each class = ImageMorph] was a great idea!!! While I appreciate the post and you know I love your inspector, I wonder, isn't there a bug? If I try to open the halos on the picture, it actually takes the World. Is this the expected behavior? Thanks! On Tue, Aug 13, 2013 at 5:53 PM, Tudor Girba tu...@tudorgirba.comwrote: Hi, I could not resist: here is a little blog post about removing your troublesome morph :) http://www.humane-assessment.com/blog/spotting-a-troublesome-image-morph Cheers, Doru On Tue, Aug 13, 2013 at 2:21 PM, Mariano Martinez Peck marianop...@gmail.com wrote: This one is more fun (ImageMorph fromStream:( ZnClient new beOneShot; url: 'http://www.gravatar.com/avatar'; addPathSegment: (ZnDigestAuthenticator md5Hash: ' marianop...@gmail.com'); queryAt: #s put: '128'; queryAt: #d put: '404'; get) readStream) openInWorld uhhh but I cannot remove the morph from the worlddamn it! On Mon, Aug 12, 2013 at 7:46 PM, Sven Van Caekenberghe s...@stfx.euwrote: Hi, Related to the usage of Gravatars ( http://en.wikipedia.org/wiki/Gravatar) for http://contributors.pharo.org here is some code you can use to check whether your Gravatar image really works: ZnClient new beOneShot; url: 'http://www.gravatar.com/avatar'; addPathSegment: (ZnDigestAuthenticator md5Hash: 's...@stfx.eu'); queryAt: #s put: '128'; queryAt: #d put: '404'; get; isSuccess. ZnClient new beOneShot; url: 'http://www.gravatar.com/avatar'; addPathSegment: (ZnDigestAuthenticator md5Hash: ' nobody.at@gmail.com'); queryAt: #s put: '128'; queryAt: #d put: '404'; get; isSuccess. (ZnClient new enforceHttpSuccess: true; beOneShot; url: 'http://www.gravatar.com/avatar'; addPathSegment: (ZnDigestAuthenticator md5Hash: ' tu...@tudorgirba.com'); queryAt: #s put: '128'; queryAt: #d put: '404'; contentReader: [ :entity | ImageMorph fromStream: entity readStream ]; get) openInWindow. And now you know how simple Gravatars really are, provided you use a proper programming language to access them. Enjoy! Sven -- Mariano http://marianopeck.wordpress.com -- www.tudorgirba.com Every thing has its own flow -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] inria jenkins got much faster
Hi, I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. It seems that the difference started yesterday before 15:00: https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) As it affected multiple jobs, I suspect it has to do with the infrastructure. Anyone has any idea as to why this happens? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] inria jenkins got much faster
Yes, we are always using the latest :). I just saw now the report about #20619. http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/81515 Wow, this is a phenomenal boost! Thank you very much. Doru On Wed, Aug 14, 2013 at 11:46 AM, Esteban Lorenzano esteba...@gmail.comwrote: if you are using latest 2.0, that's probably because the integration of the RPackageSet cache. the previous slowdown was exponential, so big projects like moose took *really* much time to load. Esteban On Aug 14, 2013, at 11:43 AM, Tudor Girba tu...@tudorgirba.com wrote: Hi, I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. It seems that the difference started yesterday before 15:00: https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) As it affected multiple jobs, I suspect it has to do with the infrastructure. Anyone has any idea as to why this happens? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] XML writer in the default image
+1 On Thu, Aug 15, 2013 at 10:10 AM, Esteban Lorenzano esteba...@gmail.comwrote: +1 On Aug 15, 2013, at 9:41 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Aug 15, 2013, at 2:15 AM, Camillo Bruni camillobr...@gmail.com wrote: As reported a while ago ( https://pharo.fogbugz.com/default.asp?7412#80347), the TestRunner is crashing when test failures accidentally spit out XML sensitive characters: https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm,label=pharo-linux64.ci.inria.fr/consoleFull I don't really see a reason to generate XML by concatenating strings, so I wonder whether we could include the XMLWriter in the default image? Why don't we load HDTestRunner when needed? And HDTestRunner could then use XMLWriter This way I could finally fix the HDTestRunner with very little effort. I will finish to pop up my list and start to work on managing the image with Metacello because we should build it based on subproject RB Nautilus Athens NativeBoost AsmJit Zinc OPAL were/are managed with metacello so we could be there :) Stef -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Installing Rubrik into 3alpha
Just make sure it still works on Pharo 2.0 for a little while. Doru On Thu, Aug 15, 2013 at 12:08 PM, Esteban Lorenzano esteba...@gmail.comwrote: Hi, I tried to install Rubrik in 3alpha (yes, yes, I know... is development, etc., etc., but I wanted to test precisely how it is behaving a text package with the changes we are introducing :) ) Well... configuration fails because there is a repeated slot, enabledHolder. This is because RubTextModel is shadowing a property that already exists on AbstractBasicWidget (and that's not allowed with new opal compiler). Now... I just removed it on RubTextModel and everything is working so... I wonder if this change could be introduced so I can continue playing without need to hack it each time? ;) cheers, Esteban -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] WhatsUp from: 2013-08-19 until: 2013-08-31
Hi, ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS - Significant Moose cleaning and preparation for the release - Strenghtening Snapshotcello (a new release is available for Pharo 2.0) - Working on a robust and configurable object traverser - Working with Andrei on some exciting new debuggers (yes, you read right: we are working on multiple debuggers that can be customized and interchanged. it's so cool) - Continue work on a new Coder design - Wrote more blog posts about using Moose for solving specific problems ( http://humane-assessment.com) ### What's next, until 2013-08-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION - Release Moose - Finish the object traverser Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] reflection examples
Hi, I am preparing a set of talks that have reflection at the center. Obviously, I want to use Pharo to demonstrate reflection. I am now looking for examples that can be explained to programmer newbies (actually, managers). I am particularly looking for examples that include adaptation (not just inspection) and that can show that reflection is valuable. I already have some examples in mind, but they might not appear particularly valuable. For example: - inspecting a class: Object methods. - adapting a class: Object compile: 'answer ^ 42'. Any suggestions? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] reflection examples
Hi, On Tue, Aug 20, 2013 at 10:40 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Aug 20, 2013, at 10:29 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi, I am preparing a set of talks that have reflection at the center. Obviously, I want to use Pharo to demonstrate reflection. I am now looking for examples that can be explained to programmer newbies (actually, managers). I am particularly looking for examples that include adaptation (not just inspection) and that can show that reflection is valuable. I already have some examples in mind, but they might not appear particularly valuable. For example: - inspecting a class: Object methods. - adapting a class: Object compile: 'answer ^ 42'. Scaffolding patterns (read them) Increase productivity when brainstorming. What patterns are you referring to specifically? Any link? Use DNU to compile on the fly some methods or to copy methods when you are designing a new piece of functionality Yes, that is a nice path, and I am looking for specific scenarios that can be used for a short demo. Any ideas? Proxy how to implement them nicely Proxies are indeed interesting and not difficult to explain, but the examples I think of (such as a facade, or a logger) do not really show adaptation. Does anyone have other examples? Cheers, Doru Any suggestions? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] default of completion
Completion should always be on. If it is perceived to be not useful, it means the completion identification mechanism must be improved. Turning the completion off will not make it likely to improve the mechanism behind. Doru On Wed, Aug 21, 2013 at 3:02 PM, Camillo Bruni camillobr...@gmail.comwrote: use startup preferences and your done. @rmod we prefer it on. On 2013-08-21, at 15:00, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! Should it not be better to have the automatic code completion turned off? 90% of the time I do not want to see it. Am I the only one to experience this? I know this has been discussed some times ago, but this is really annoying. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] -= First Visualization Contest with Roassal =-
Great idea! Doru On Fri, Aug 23, 2013 at 8:31 AM, Alexandre Bergel alexandre.ber...@me.comwrote: Dear colleagues and friends, We are happy to announce the First Visualization Contest with Roassal. What can I win? - 150 euros, sponsored by ObjectProfile - a über-cool ObjectProfile T-shirt and some wonderful stickers - maximum publicity of your work - a nice award certificate, delivered during ESUG How can I win? - you have to produce a visualization with Roassal. You can use the Pharo, VisualWorks or VAST version of Roassal. Here is an example of what we expect http://bit.ly/sunburstDemo - making a video is mandatory. The video will weight the most in our decision. The video could be of any length and has to include your name and say that is was made (partly or completely) with Roassal. No need to talk, just show off! - making your code available and easy to install will help you get more points How can I submit? - send the links of your video and other material (if needed) to i...@objectprofile.com Every email you will send to this email will be acknowledged. If you do not receive a 'Ok' from us, it means we haven't read it, in that case send your email again after a few days. - the deadline for submitting is September 4, 2013 Mini FAQ? - Is the object-profile team allowed to participate? No - Should my visualization or code be open source? No need for this, whatever license is fine. However your video should be made public. - How can I get more information? Just comment on the facebook https://www.facebook.com/ObjectProfile or using Twitter @ObjectProfile or send email to i...@objectprofile.com - What I submit twice? Yes, no problem with that - How will judge the videos? both the esug community and the object profile team. The Esug community will have 30% of the final grade, object profile the remaining 70% -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://ObjectProfile.com http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] -= First Visualization Contest with Roassal =-
Let's try to keep the noise going about this: http://www.moosetechnology.org/news/roassal-visualization-competition I think it would be cool to see the submissions as they get submitted. Doru On Fri, Aug 23, 2013 at 10:49 AM, Tudor Girba tu...@tudorgirba.com wrote: Great idea! Doru On Fri, Aug 23, 2013 at 8:31 AM, Alexandre Bergel alexandre.ber...@me.com wrote: Dear colleagues and friends, We are happy to announce the First Visualization Contest with Roassal. What can I win? - 150 euros, sponsored by ObjectProfile - a über-cool ObjectProfile T-shirt and some wonderful stickers - maximum publicity of your work - a nice award certificate, delivered during ESUG How can I win? - you have to produce a visualization with Roassal. You can use the Pharo, VisualWorks or VAST version of Roassal. Here is an example of what we expect http://bit.ly/sunburstDemo - making a video is mandatory. The video will weight the most in our decision. The video could be of any length and has to include your name and say that is was made (partly or completely) with Roassal. No need to talk, just show off! - making your code available and easy to install will help you get more points How can I submit? - send the links of your video and other material (if needed) to i...@objectprofile.com Every email you will send to this email will be acknowledged. If you do not receive a 'Ok' from us, it means we haven't read it, in that case send your email again after a few days. - the deadline for submitting is September 4, 2013 Mini FAQ? - Is the object-profile team allowed to participate? No - Should my visualization or code be open source? No need for this, whatever license is fine. However your video should be made public. - How can I get more information? Just comment on the facebook https://www.facebook.com/ObjectProfile or using Twitter @ObjectProfile or send email to i...@objectprofile.com - What I submit twice? Yes, no problem with that - How will judge the videos? both the esug community and the object profile team. The Esug community will have 30% of the final grade, object profile the remaining 70% -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://ObjectProfile.com http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [ann] dynamic browsers with glamour
Hi, Here is a little announcement for those that like Glamour. Andrei and I worked on making Glamour more dynamic by pushing the presentation definition at execution, rather than at browser construction time. To achieve dynamic presentation creation, before you needed to use the GLMDymamicPresentation. For example, the MooseFinder was built like: MooseFindercompose self finder show: [ :a | a dynamic display: [:each | | dynamic | dynamic := GLMCompositePresentation new. each mooseInterestingEntity mooseFinderPresentationsIn: dynamic. dynamic ] ]. Now, the same code becomes: MooseFindercompose self finder show: [ :a :each | each mooseInterestingEntity mooseFinderPresentationsIn: a ]. You can see more details here: http://www.humane-assessment.com/blog/building-dynamic-browsers-with-glamour Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Rubrik, scroll to end?
I also thinks it sounds good now. I love this type of discussions. Doru On Tue, Aug 27, 2013 at 3:19 PM, Stephan Eggermont step...@stack.nl wrote: Alain wrote: Maybe something like: #scrollToEndOfText, #scrollToBeginningOfText, #scrollToEndOfLine, #scrollToBeginningOfLine. #pageUp, #pageDown, #pageLeft, #pageRight. Clear to me, thank you Stephan -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] a weak on:do:/when:do:
Does this work? Doru On Wed, Aug 28, 2013 at 11:54 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: whenListChanged: aBlock Specify a block to value after the contents of the list has changed Basically when you set a new list of items api: #event | block | block := [ :announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. listAnnouncer weak when: ValueChanged do: block -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] a weak on:do:/when:do:
That is what I knew, too. I asked because the mail seemed to suggest that it would work :). Doru On Wed, Aug 28, 2013 at 12:54 PM, Esteban Lorenzano esteba...@gmail.comwrote: no, it is not. that will keep the registry forever because it acts over a block (no ephemerons, remember) Esteban On Aug 28, 2013, at 11:56 AM, Tudor Girba tu...@tudorgirba.com wrote: Does this work? Doru On Wed, Aug 28, 2013 at 11:54 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: whenListChanged: aBlock Specify a block to value after the contents of the list has changed Basically when you set a new list of items api: #event | block | block := [ :announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. listAnnouncer weak when: ValueChanged do: block -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] It was a productive and nice sprint.
Thank you! Where can I see the pointer explorer? Doru On Wed, Aug 28, 2013 at 9:00 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Thanks all for your good energy. I will push some of the fixes in the stream too :) For the non participating guys we got - compiler fixes - faster tests - cleans in morphic - better pointer explorer - critics browser working - grease better configuration - and many more… Stef -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] It was a productive and nice sprint.
Yes! I would love to have such a tool. Doru On Thu, Aug 29, 2013 at 9:32 AM, Igor Stasenko siguc...@gmail.com wrote: On 29 August 2013 08:53, Stéphane Ducasse stephane.duca...@inria.frwrote: in the bug tracker Igor spent the day chasing bad registration hanging around and fixing the tools to let him get there. unfortunately i didn't managed to chase them all. found couple leaks, but there are more which still escaping :( what i want to do is to write small tracer which will search for local roots of set of objects. stef On Aug 29, 2013, at 7:00 AM, Tudor Girba tu...@tudorgirba.com wrote: Thank you! Where can I see the pointer explorer? Doru On Wed, Aug 28, 2013 at 9:00 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Thanks all for your good energy. I will push some of the fixes in the stream too :) For the non participating guys we got - compiler fixes - faster tests - cleans in morphic - better pointer explorer - critics browser working - grease better configuration - and many more… Stef -- www.tudorgirba.com Every thing has its own flow -- Best regards, Igor Stasenko. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Moose-dev] Some FAMIX questions
+100 Doru On Thu, Aug 29, 2013 at 9:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: nice analysis. I really hope that using smarter class structure based on Slot we can offer a solution in the future. On Aug 29, 2013, at 6:24 PM, Stephan Eggermont step...@stack.nl wrote: Currently, quite a lot of space seem to be taken up by not-filled instvars. In my Delphi based Whitestar model, 406085 out of 664371 are either nil or empty sets. In a JHotDraw model from inFusion it is 724408 out of 1351527 Stephan FAMeasurementsmeasure varSize := mClass instSize. instSize := mClass allInstances size. nrNil := 0. nrEmpty := 0. mClass allInstancesDo: [ :instance | 1 to: varSize do: [:varIndex | |value| value := instance instVarAt: varIndex. value ifNil: [ nrNil := nrNil+1 ]. value isCollection ifTrue: [ value ifEmpty: [ nrEmpty := nrEmpty+1 ] ] ] ] MeasureFAMIXinitializeMeasurements FAMIXEntity withAllSubclassesDo: [ :each | self measurements add: (FAMeasurements new mClass: each; yourself). ] MeasureFAMIXrun self initializeMeasurements. measurements do: [ :each | each measure] MeasureFAMIXsum nrOfVars := 0. nrEmpty := 0. measurements do: [ :measurement | nrOfVars := nrOfVars + (measurement varSize * measurement instSize). nrEmpty := nrEmpty + measurement nrEmpty + measurement nrNil]. In Famix-SelfMeasurements on smalltalkhub ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] No more dirty packages in Pharo
Ok, great. I loaded ConfigurationOfMagritte3 #development, and Grease loaded clean. Thank you! The only remaining problem was asMorph in Magritte-Morph, but I fixed it now, so Magritte loads clean in Pharo 2.0. Cheers, Doru On Sun, Sep 1, 2013 at 7:29 AM, Tudor Girba tu...@tudorgirba.com wrote: Great. What version? Doru On Fri, Aug 30, 2013 at 12:59 PM, Damien Cassou damien.cas...@gmail.comwrote: Hi, I've fixed Magritte and Grease configurations so that loading these projects do not dirty any pharo package anymore. Best -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill ___ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] self foo: (var := …) vs var := …. self foo: var
As far as I know, it was the same problem that induced the Metacello loading problem related with SmallInteger. Doru On Sep 1, 2013, at 5:37 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Ok, thanks! Alexandre On Sep 1, 2013, at 10:01 AM, Camillo Bruni camillobr...@gmail.com wrote: this is a VM problem, Use the latest (unstable) vm from here: http://files.pharo.org/vm/pharo/ Esteban updated the VM On 2013-09-01, at 15:02, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! I am facing a strange situation: The following expression raises an error: -=-=-=-=-=-=-=-=-= rawView add: (helpLabel := (ROElement on: 'Click here!') + ROLabel). -=-=-=-=-=-=-=-=-= Apparently, what is sent as argument to #add: is an integer. I have to update my code with : -=-=-=-=-=-=-=-=-= (helpLabel := (ROElement on: 'Click here!') + ROLabel). rawView add: helpLabel. -=-=-=-=-=-=-=-=-= To not have an error. This is really strange! By the way, this looks like the issue with Metacello? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every successful trip needs a suitable vehicle.
Re: [Pharo-dev] Distributing File Resources
Hi Jeff, Would you have an interest looking into this and prototyping a solution? Doru On Tue, Sep 3, 2013 at 12:44 PM, J.F. Rick s...@je77.com wrote: I'm surprised this doesn't exist yet. It seems like it would be a natural thing to be part of Monticello. Cheers, Jeff On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker marcus.den...@inria.frwrote: What I would like to have is - A way to save files per package in the image in a virtual file system - Monticello support to save that virtual file system as part of the .mcz We could clean up *a lot* of methods in the image and even save memory: right now the save Base64 encoded strings in methods means that we have the data two times: the string literal and the object created from it. (and the source on disk). On Sep 3, 2013, at 11:23 AM, p...@highoctane.be wrote: yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh
+1 Doru On Wed, Sep 4, 2013 at 2:13 PM, Camillo Bruni camillobr...@gmail.comwrote: I really liked it! thanks for the link :) On 2013-09-04, at 06:34, Sven Van Caekenberghe s...@stfx.eu wrote: Pretty well written piece about real documentation: http://stevelosh.com/blog/2013/09/teach-dont-tell/ Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] The Moldable Debugger Framework
Hi, Great job, Andrei! Just a couple of complementary remarks: - Moldable tools offer a significant departure from the original Smalltalk environment. Just think about it: we pride ourselves on our live environment, yet the default tools are utterly static. In contrast, the moldable debugger lets you switch change your debugging tools while debugging. Another example from the same family is the GTInspector: there too you can switch the inspection workflow and presentation while inspecting. Live should describe everything in our environment, not just the code model. - The Moldable Debugger also brings enhanced presentations into the debugger. For example, in the Glamour-specific debugger instead of only textual presentations of your objects, you get a visualization that shows the schematics of your browser. - But, the Moldable Debugger is not just a debugger or a collection of debuggers, it's an engine for building your own debuggers. And the great thing about it is that it makes it cheap. A couple of hundred lines of code cheap. This was made possible through to a complete rewrite of the debugger model that is essentially integrated in Pharo 3.0. - By making it cheap, a moldable tool opens another door: if you spend your energy building a framework, you should spend a little fraction of the overall effort and ship dedicated tools to handle that framework, too. This can increase the value of your framework significantly. For example, in Moose, we now have a browser dedicated for developing and analyzing parsers, we have debuggers for PetitParser and Glamour, we have dedicated editors for building interactive tools like Roassal or Glamour, and we have enhancements to the GTInspector for various object types we work often with. This makes Moose much more than a library: it makes it a versatile environment with which you can craft your own analyses cheaply. Yet, the cost of these additional tools is tiny compared with the overall cost of building the engines. All in all, please take a bit of time and look into this work. Moose offers examples of how it looks in practice, but the moldable tools should be used for any Pharo project. Yes, having worked on this I am biased, but I believe if we go on this route we can redefine what the IDE means. And this can be a huge opportunity both for Pharo and for Moose. Cheers, Doru On Sun, Sep 8, 2013 at 12:31 AM, Andrei Vasile Chis chisvasileand...@gmail.com wrote: Hi, I'd like to announce the first version of the Moldable Debugger. It is a framework for creating and working with domain specific debuggers. It's integrated into Moose and it currently comes with three debuggers: one for announcements, one for PetitParser and one for Glamour. More information can be found here: * http://scg.unibe.ch/research/moldabledebugger* A video introducing the framework is here: *https://vimeo.com/73980431* (more are on the way) Cheers, Andrei -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] cannot commit with gofer to sthub (HTTP 403)
Hi, It seems that I cannot commit with Gofer on STHub. I get a 403. If I do it via the regular Monticello browser, it works just fine. I am on the latest Pharo 2.0 and I use a script that goes like this: Gofer new url: 'http://www.smalltalkhub.com/mc/Moose/MooseAlgos/main/'; package: 'ConfigurationOfMooseAlgos'; commit: 'version generated by Snapshotcello' with the url being already authenticated beforehand. I also tried by passing the url:username:password: explicitly, but this has the same 403 effect. Anyone knows what the issue is? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] cannot commit with gofer to sthub (HTTP 403)
As I said, I was using the latest Pharo 2.0. Doru On Tue, Sep 10, 2013 at 9:36 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: which version of the image are you using? Stef Hi, It seems that I cannot commit with Gofer on STHub. I get a 403. If I do it via the regular Monticello browser, it works just fine. I am on the latest Pharo 2.0 and I use a script that goes like this: Gofer new url: 'http://www.smalltalkhub.com/mc/Moose/MooseAlgos/main/'; package: 'ConfigurationOfMooseAlgos'; commit: 'version generated by Snapshotcello' with the url being already authenticated beforehand. I also tried by passing the url:username:password: explicitly, but this has the same 403 effect. Anyone knows what the issue is? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] cannot commit with gofer to sthub (HTTP 403)
Hi, Yes, I know that. I was just saying that I tried multiple variations just in case someone wanted to know. The debugger is not particularly helpful here: I just get a 403 response which means that the authentication fails. I cannot see where the problem is. Cheers, Doru On Tue, Sep 10, 2013 at 7:22 PM, MartinW w...@fastmail.fm wrote: Tudor Girba-2 wrote with the url being already authenticated beforehand. I also tried by passing the url:username:password: explicitly, but this has the same 403 effect. Anyone knows what the issue is? At least I know that second part: *If the repository is already present* in the image sending url:username:password: to a Gofer instance has no effect at all. So if your repository is in the image without username and password sending url:username: 'correctName' password: 'correctPassword' will change nothing. You have to manually edit the repository info. On the other hand - if you have a repository with correct username and password you can send url:username: 'someNonsense' password: 'wrongPassword' and everything will still work correctly. If you just get something via Gofer from a public repository you have the repository added by Gofer and when you later want to push to the repository via Gofer and provide your username and password - you get an error. That's why i was asking about programatically manipulating repositories: http://stackoverflow.com/questions/18100136/manipulating-repositories-for-specific-monticello-packages-programatically -- View this message in context: http://forum.world.st/cannot-commit-with-gofer-to-sthub-HTTP-403-tp4707412p4707523.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [ann] moose 4.8
We are happy to announce version 4.8 of the Moose Suite: http://moosetechnology.org/download/4.8 Description -- This was supposed to be a minor release, but in the end it turned out to be a major release with significant improvements. The key highlights are: - Based on Pharo 2.0. - All built-in visualizations use Roassal. - Roassal received a significant performance boost and new smart graph layouts like TreeMapLayout or ForceBasedLayout. - Roassal uses Athens for nice looking vectorial graphics. - New charting engine based on Roassal: Graph-ET. - Glamour changed to enable dynamic scripts, while still remaining backward compatible. - Glamour received a RubricTextPresentation for using the new Rubric text morph. - Glamour, Roassal, EyeSee, Graph-ET editors are more robust when dealing with errors in scripts.- New GTDebugger with dedicated workflows for Announcements, PetitParser and Glamour itself. - Extended GTInspector for several object types. - Usable version of GTMetaceller for handling Metacello configurations. - FAMIX was strengthen to handle functions better in various programming languages. - New free type fonts and simpler whitespace-loving theme. - Lower memory footprint for large models. - Faster MSE import. A list of issues addressed in this release can be found at: http://code.google.com/p/moose-technology/issues/list?can=1q=status=Fixed%20milestone=4.8 Installation -- The Moose Suite 4.8 comes for each platform as a separate bundle: - Mac: https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_8-mac.zip - Windows: https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_8-win.zip - Linux: https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_8-linux.zip The Moose Suite 4.8 can also be loaded in a Pharo 2.0 image either from the Configuration Browser, or by executing the following script: Gofer new smalltalkhubUser: 'Moose' project: 'Moose'; package: 'ConfigurationOfMoose'; load. ((Smalltalk at: #ConfigurationOfMoose) project version: '4.8-snapshot') load Enjoy, The Moose Team -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [ann] moose 4.8
Yeah, I used to work with Smalltalk quite a lot. Now, I only work with Pharo, and I do not miss Smalltalk at all :) Doru On Fri, Sep 13, 2013 at 11:11 AM, Damien Cassou damien.cas...@gmail.comwrote: On Fri, Sep 13, 2013 at 11:05 AM, Serge Stinckwich serge.stinckw...@gmail.com wrote: Ouaa, there is still PL/1 on the earth ? yes! and Smalltalk too :-) -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [ann] moose 4.8
Pharo is Pharo :) http://www.tudorgirba.com/blog/pharo-is-pharo Doru On Fri, Sep 13, 2013 at 11:18 AM, kilon theki...@yahoo.co.uk wrote: pharo is not smalltalk ? o_O it certainly fooled me -- View this message in context: http://forum.world.st/ann-moose-4-8-tp4707988p4708053.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Seaside News] Smalltalkhub, ConfigurationOfSeaside3, Seaside3.1
Great work! Doru On Sep 14, 2013, at 10:33 AM, Johan Brichau jo...@inceptive.be wrote: Hi Seasiders, The Seaside repository moved to Smalltalkhub, a new ConfigurationOfSeaside3 was created and Seaside 3.1 is in release candidate mode. Current stable release for all platforms is 3.0.8 (with a final bugfix release 3.0.9 coming up). Seaside 3.1 has all tests green on Pharo 1.4 and 2.0. We are working on Gemstone and Squeak Seaside and all Seaside team curated projects can be found here: http://www.smalltalkhub.com/#!/~Seaside We have grouped all Metacello configurations for these projects in a single repository: http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main Important: there now is a single configuration for both Seaside 3.0 and Seaside 3.1: ConfigurationOfSeaside3 To load current stable Seaside 3.0.8: Gofer new url: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; package: 'ConfigurationOfSeaside3'; load. ((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load To load Seaside 3.1.0: ((Smalltalk at: #ConfigurationOfSeaside3) project version: '3.1.0') load Stay tuned for a follow-up email on Seaside3.1 For the Seaside team, Johan, Philippe, Dale, John -- www.tudorgirba.com To utilize feedback, you first have to acquire it.
Re: [Pharo-dev] moose build under 2.0
Hi, We typically load development on the CI server: REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development But, I think you are doing something else other than loading the code, and I think the problem is that at least in the version that we load, Grease defines its own package implementation which conflicts with RPackage. Could you confirm? Cheers, Doru On Sep 16, 2013, at 8:51 PM, Camillo Bruni camillobr...@gmail.com wrote: I'm trying to fix the VM acceptance test. I currently have troubles loading moose. What is the standard location of the configuration for Pharo 2.0? +++ + ./pharo ./Pharo.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=stable === Notice: Installing ConfigurationOfMoose stable === Startup Error: GRError: 'Grease-Tests-Pharo-Core' depends on unknown package 'Grease-Pharo-Core' GRPackage class(GRObject class)error: GRPackage(GRObject)error: GRPackageresolveWith: in Block: [self error: self name printString , ' depends on ...etc... Dictionaryat:ifAbsent: GRPackageresolveWith: in Block: [:each | aDictionary... OrderedCollectioncollect: GRPackageresolveWith: GRPackage classpackages in Block: [:each | each resolveWith: packages] ... +++ -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one.
Re: [Pharo-dev] moose build under 2.0
Indeed. Torsten pointed out the same thing. We will look into it. Doru On Sep 16, 2013, at 11:15 PM, Camillo Bruni camillobr...@gmail.com wrote: actually you pointed out the problem :) we previously load seaside into the same image, seems like the grease versions do not like each other very much ;) On 2013-09-16, at 17:26, Tudor Girba tu...@tudorgirba.com wrote: Hi, We typically load development on the CI server: REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development But, I think you are doing something else other than loading the code, and I think the problem is that at least in the version that we load, Grease defines its own package implementation which conflicts with RPackage. Could you confirm? Cheers, Doru On Sep 16, 2013, at 8:51 PM, Camillo Bruni camillobr...@gmail.com wrote: I'm trying to fix the VM acceptance test. I currently have troubles loading moose. What is the standard location of the configuration for Pharo 2.0? +++ + ./pharo ./Pharo.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=stable === Notice: Installing ConfigurationOfMoose stable === Startup Error: GRError: 'Grease-Tests-Pharo-Core' depends on unknown package 'Grease-Pharo-Core' GRPackage class(GRObject class)error: GRPackage(GRObject)error: GRPackageresolveWith: in Block: [self error: self name printString , ' depends on ...etc... Dictionaryat:ifAbsent: GRPackageresolveWith: in Block: [:each | aDictionary... OrderedCollectioncollect: GRPackageresolveWith: GRPackage classpackages in Block: [:each | each resolveWith: packages] ... +++ -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one. -- www.tudorgirba.com What is more important: To be happy, or to make happy?
[Pharo-dev] scripts for automating the moose release
Hi, I wrote a little blog post describing the process of releasing Moose: http://www.humane-assessment.com/blog/automating-moose-4-8-release Perhaps this might be useful for others. And perhaps we can find ways to improve it. Cheers, Doru -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal.
Re: [Pharo-dev] Seaside Continuous Integration on ci.inria.fr
+100 This is so important. Doru On Sep 16, 2013, at 6:09 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I deeply appreciate your effort and I want to thank the seaside group. Stef On Sep 16, 2013, at 11:20 AM, Philippe Marschall kus...@gmx.net wrote: Hi This is a short write up on the state of Seaside on ci.inria.fr. After a week of work we have Metacello based builds running green at ci.inria.fr. Grease 1.0 and 1.1 are green on both Pharo 2.0 and 3.0 [1]. Updating Pier 3 to use the latest Grease 1.0 should fix the Pier 3 build. For Seaside 3.x we load the Metacello group 'CI' and run the tests in the packages matching the following regex ((Seaside)|(Comet)|(Javascript)|(RSS)|(JQuery)|(Prototype)|(Scriptaculous))-.*. Currently we have no way of running SLint/Slime and fake Checkstyle like in [3]. If anybody knows how to do with please let us know. There are still some issues with file library in Pharo 3.0 and Seaside 3.0. They are only fixed in Seaside 3.1. Please try to keep the build green, otherwise we'll get spammed with emails. Currently we keep all the build (5GB already). Do we really need this? [1] https://ci.inria.fr/pharo-contribution/job/Grease/ [2] https://ci.inria.fr/pharo-contribution/job/Seaside/ [3] http://jenkins.lukas-renggli.ch/view/Seaside%203.1/job/Seaside%203.1/ Cheers Philippe -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower.
Re: [Pharo-dev] Smalltalkhub = 503
Thank you, Nicolas. Just for the record: Although people send mails mostly when SmalltalkHub is down, I am sure everyone is happy that SmalltalkHub exists. I for one am :) Doru On Tue, Sep 17, 2013 at 5:40 PM, Guillermo Polito guillermopol...@gmail.com wrote: Thanksss :) On Tue, Sep 17, 2013 at 5:32 PM, nicolas petton petton.nico...@gmail.comwrote: Hi! It's up again. Mongo was down for some reason, I'm looking at it now. Sorry for the inconvenience, Nico 2013/9/17 Guillermo Polito guillermopol...@gmail.com it's down and I need to commit!! -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Moose-dev] Code functionality assessment
I blogged it:) http://www.moosetechnology.org/news/assessing-ode-with-graphet Cheers, Doru On Mon, Sep 23, 2013 at 7:36 PM, Tudor Girba tu...@tudorgirba.com wrote: Very nice work, Natalia! Doru On Mon, Sep 23, 2013 at 6:12 PM, Natalia Tymchuk natalia.tymc...@unikernel.net wrote: Hello, I wrote another blog post concerning my project on Google Summer of Code, and there's how I assessed the results using Graph-ET. http://nataliatymchuk.blogspot.com/2013/09/code-functionality-assessment.html Best regard, Natalia ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Moose-dev] Code functionality assessment
Very nice work, Natalia! Doru On Mon, Sep 23, 2013 at 6:12 PM, Natalia Tymchuk natalia.tymc...@unikernel.net wrote: Hello, I wrote another blog post concerning my project on Google Summer of Code, and there's how I assessed the results using Graph-ET. http://nataliatymchuk.blogspot.com/2013/09/code-functionality-assessment.html Best regard, Natalia ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Dynamically adding nodes to Roassal
You would get answers to these questions faster on the moose mailing list. Doru On Mon, Sep 30, 2013 at 8:13 AM, roberto.mine...@usi.ch roberto.mine...@usi.ch wrote: Anyone can help here? On Sep 20, 2013, at 5:32 PM, roberto.mine...@usi.ch wrote: Hi, It's me again.. I managed to have something *almost* working, but the behavior of the ROTreeMapLayout is not clear to me. Using the ROMondrianViewBuilder I can specify the size of the Tree map, but then I am not able to dynamically add nodes. Well, at least I did not manage to do that. So I moved to pure Roassal, as suggested by Alejandro. Here's how my actual code looks like: http://ws.stfx.eu/CFM522Z9X3ES I am a beginner with Roassal, so I spend some time to figure out how to draw the tree map in this way. I did not really quite understand why I have to add the ROBox new size: 200 to the ROElement, but I'll figure it out. The thing is when I try to add the new node. Following, again, Alejandro's advice I am writing something like: I add a new node, re-layout the view, and signalUpdate rawView add: ((ROElement on: 10) + (ROBox new size: 200)). (ROTreeMapLayout withWeightBlock: [ :e | e model ]) applyOn: rawView elements. rawView signalUpdate . The result is quite strange, the view is indeed updated but I cannot understand why all sizes are messed up. My questions, in short are: How can I fix the overall size of the tree map? Am I doing everything correct till now? Thanks again for your help, Roby On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch wrote: Hi, I was playing around with Roassal (in particular, a tree map) and I have a question: Is there a way to dynamically adding nodes? I mean, once the view is generated to update the #nodes by adding a new node (and associations as well, i.e., edges) and have the visualization re- Thanks in advance. Roby -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] failing moose tests
You would get this problem anyway. Let's fix the current development version and the we resnapshot. In the longer term we will see how the enhancements from Diego can help. Doru Sent from my iPhone On Oct 2, 2013, at 10:28, Stephan Eggermont step...@stack.nl wrote: (from pharo -dev) PharoVM-AcceptanceTest loads Moose-Stable. That is based on a snapshot. As the snapshot flattens the configuration, it is basically unpatchable. Stephan
Re: [Pharo-dev] Any visualisation for Metacello?
Indeed. And if you need some other information than the one shown, just let us know and we can try to add it. Doru On Thu, Oct 3, 2013 at 10:13 AM, Christophe Demarey christophe.dema...@inria.fr wrote: Gofer new url: 'http://www.smalltalkhub.com/mc/Moose/GToolkit/main'; package: 'ConfigurationOfGToolkit'; load. (Smalltalk at: #ConfigurationOfGToolkit) project development load. (Smalltalk at: #GTMetaceller) open. Le 2 oct. 2013 à 19:03, Stéphane Ducasse a écrit : metaceller in the moose image maybe On Oct 2, 2013, at 6:29 PM, Damien Cassou damien.cas...@gmail.com wrote: Hi, I have to deal with complex configurations involving Pier (and some of its plugins), Magritte, Voyage, Mongo and Seaside. There is a bug somewhere because I can't load all of that. Is there any tool that would show me a graph of the projects and their dependencies? If there is no graph, is there at least some place to get the information? I know the #record + #loadDirective combo, but I don't understand the result and it does not help. Best -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [ann] system attraction view
Hi, I built a new visualization that has two goals: 1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo. A description of mainly point 1. can be found here: http://www.humane-assessment.com/blog/system-attraction/ I already used it as a splash screen for a couple of presentations, and it catches the eye. The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups). Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Pharo (cog) Vm on Windows with 2GB virtual mem
Hi, As far as I can tell, you should set the limit in MBytes. So, for 2G, you should have: AddressSpaceLimit=2048 I am using 1GB for some Moose analyses. I benchmarked and got no sign of slowdown. Cheers, Doru On Fri, Oct 4, 2013 at 6:10 AM, Oscar EA Callaú oalva...@dcc.uchile.clwrote: Thanks a lot, I added ** ** AddressSpaceLimit = 2147483648 ** ** To the .ini file and all is working smoothly. ** ** FYI, I don’t have speed problems with such memory. Of course, If I’ll process some big data, I’ll wait a while to get the answer, but the same happens in any other lang/platt. Certainty, I can do fast experiments in C, but I don’t get all Pharo benefits, like pausing my analysis and resuming it later, such thing in C (or may be any other language) would require to store the intermediate data into files or a database. With Pharo, I don’t care about that. ** ** Cheers. ** ** *From:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] *On Behalf Of *Guillermo Polito *Sent:* Thursday, October 3, 2013 2:37 AM *To:* Pharo Development List *Subject:* Re: [Pharo-dev] Pharo (cog) Vm on Windows with 2GB virtual mem* *** ** ** I can only guess by the comment in the commit: ** ** https://gitorious.org/cogvm/blessed/commit/341e6c2e150bcde80dfea6c890bab7745b2a6d44 ** ** Can you check that? ** ** Guille ** ** On Thu, Oct 3, 2013 at 6:36 AM, Oscar EA Callaú oalva...@dcc.uchile.cl wrote: Thanks, but what would be the parameter? This is the default .ini [Global] DeferUpdate=1 ShowConsole=0 DynamicConsole=1 ReduceCPUUsage=1 ReduceCPUInBackground=0 3ButtonMouse=0 1ButtonMouse=0 UseDirectSound=1 PriorityBoost=1 B3DXUsesOpenGL=0 CaseSensitiveFileMode=0 So there is no mention the paratemer to change or add. Cheers. *From:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] *On Behalf Of *Guillermo Polito *Sent:* Friday, September 27, 2013 5:18 AM *To:* Pharo Development List *Subject:* Re: [Pharo-dev] Pharo (cog) Vm on Windows with 2GB virtual mem* *** I think latest Pharo VM supports to change the memory limit by only changing an ini file. Igor did that not long ago. Cheers, Guille On Fri, Sep 27, 2013 at 2:09 PM, Oscar E. A. Callaú oalva...@dcc.uchile.cl wrote: Hi Guys, I read in this thread http://forum.world.st/out-of-memory-cog-on-windows-td3465621.html that 512 mb limit can be avoided in windows, but a re-compilation is needed. I was wondering if the situation changed, and now we can pass a parameter. Otherwise, I would be interested if any of you has a pre-compiled vm with more mem. I need to run some experiments and I need 2GB (or 1.5 GB at least ) on a cog VM for Windows. Thanks in advance. Oscar ** ** -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [ann] system attraction view
Hi, On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry thierry.goub...@cea.frwrote: Hi Tudor, I found your visualisation very interesting, and wondered about one thing linked to your blog post and if I got it right. The visualisation you're showing is able to show, at the single class level, if a class is more or less regular (i.e. tidy == well designed?) but you show that it will loose very shortly it's tidy shape if the classes it joins to are added to the visualisation. And I wondered if this was a choice on the graph layout algorithm you've choosen, i.e. that maintaining the tidiness of the class could be done with a different layout algorithm? Maybe one which has a measure of tidiness of the class at the local level, and weight it against the position and attraction of its links to the other components in the application? My argumentation is that if we look at a class isolated it will have a certain shape, and because we are exposed to this view (the IDE is always showing me only that) all the time we will optimize it such that the shape is tidy. But if we look at the class in the context of its interactions the shape will be less recognizable. The chosen layout is a very simple one, and the goal is not to say whether the structure is good or bad. This is neither good nor bad. It simply argues how steering the architecture has to take these forces into account. In the mean time, I'm slowly discovering we have amazing software architecture visualisation tools :) They really are amazing :). If you want to get more information about it, you can join the Moose mailing list: http://www.moosetechnology.org/about/contact Would really like to setup a project on that if I get the chance. What do you mean? What kind of a project? Cheers, Doru Regards, Thierry Le 03/10/2013 23:34, Tudor Girba a écrit : Hi, I built a new visualization that has two goals: 1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo. A description of mainly point 1. can be found here: http://www.humane-assessment.**com/blog/system-attraction/http://www.humane-assessment.com/blog/system-attraction/ I already used it as a splash screen for a couple of presentations, and it catches the eye. The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups). Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [ANN] Mustache templates
Very nice! Doru On Fri, Oct 4, 2013 at 1:47 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 04 Oct 2013, at 12:58, Norbert Hartl norb...@hartl.name wrote: Am 04.10.2013 um 12:32 schrieb Alexandre Bergel alexandre.ber...@me.com : What is a mustache template? http://norbert.hartl.name/blog/2013/10/03/mustache-templates-for-smalltalk/ Nice! Norbert On 4 Oct 2013, at 03:56, Torsten Bergmann asta...@gmx.de wrote: I like to announce my smalltalk port of mustache templates. Cool! To load it do Consider making a copy into MetaRepoForPharo20 or MetaReporForPharo30 if it is working in these versions. That way it is easily accessible via Config browser. Thx T. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [ann] system attraction view
Hi, On Fri, Oct 4, 2013 at 2:42 PM, Goubier Thierry thierry.goub...@cea.frwrote: Le 04/10/2013 14:14, Tudor Girba a écrit : Hi, On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr** wrote: Hi Tudor, I found your visualisation very interesting, and wondered about one thing linked to your blog post and if I got it right. The visualisation you're showing is able to show, at the single class level, if a class is more or less regular (i.e. tidy == well designed?) but you show that it will loose very shortly it's tidy shape if the classes it joins to are added to the visualisation. And I wondered if this was a choice on the graph layout algorithm you've choosen, i.e. that maintaining the tidiness of the class could be done with a different layout algorithm? Maybe one which has a measure of tidiness of the class at the local level, and weight it against the position and attraction of its links to the other components in the application? My argumentation is that if we look at a class isolated it will have a certain shape, and because we are exposed to this view (the IDE is always showing me only that) all the time we will optimize it such that the shape is tidy. But if we look at the class in the context of its interactions the shape will be less recognizable. The chosen layout is a very simple one, and the goal is not to say whether the structure is good or bad. This is neither good nor bad. It simply argues how steering the architecture has to take these forces into account. Hum, my point would be that a locally well designed class is a factor to strive for; also that the overall architecture has it's impact on it as well, but not so as to so easily erase the local good property when looking at the visualisation, otherwise the latter may not end up so usefull, that's all. I do agree with your point, I just believe the layout could carry a bit more insight in trying to both show the local property the code was trying to achieve (and areas where it failed) and the emergence of the architecture coupling on it. Your representation seemed to imply that local good design is unimportant in the architectural view, and I'm sure this is not what it is supposed to convey. There are many visualizations that try to capture good and bad, but I distinctly did not want the visualization to be about this. It is about how context changes the shape. As a consequence, architecture does not exist without the context, and as the context evolves in millions of little ways, so does architecture. Constantly. That is all. The main goal is to support technical people argue when discussing with managers, rather than necessarily having a say about the value. But, here is a challenge: would you like to play with it and propose a different approach? Btw, the current implementation has 19 lines :). In the mean time, I'm slowly discovering we have amazing software architecture visualisation tools :) They really are amazing :). If you want to get more information about it, you can join the Moose mailing list: http://www.moosetechnology.**org/about/contacthttp://www.moosetechnology.org/about/contact I'll do once I have a strong/practical incentive :) I know its there, Stéphane showed a lot of interesting things in it when he came here, but I didn't managed to organize things around that subject. Would really like to setup a project on that if I get the chance. What do you mean? What kind of a project? Collaborative R or RD project :) Only way I can justify working on something like that... A good fit would be visualisation of large software in my lab expertise area : high performance and real time massively parallel software on embedded systems. Perhaps you can get some inspiration of places to use Moose in on the humane-assessment.com site. In particular, on the blog I try to offer examples and stories for how assessment should change the face of development :). Cheers, Doru Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [update 3.0] #30446
Impressive is the right word, indeed :) Doru On Fri, Oct 4, 2013 at 12:08 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 04 Oct 2013, at 10:53, Marcus Denker marcus.den...@inria.fr wrote: 30446 - 11719 integrate all the changes from the repository of the new debugger https://pharo.fogbugz.com/f/cases/11719 This commit contains the following main changes: - debugging actions are first class entities; they are defined in separate classes. All actions from the toolbar are added dynamically based on pragmas. - separated the spec interface into multiple widgets: stack, toolbar, buttons - have dedicated filters to hide contexts from the stack Thanks to Clara Allende and Andrei Chis! Impressive stuff ! Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.160.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Settings-Tools-MarcusDenker.48.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.76.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.60.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerFilters-MarcusDenker.4.diff -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] about creating Morphic-Widgets
+1 Doru On Sun, Oct 6, 2013 at 10:28 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I am in for splitting Morphic in more that one package. It makes things really boring to have every thing in one MC Package :( Ben On Oct 6, 2013, at 8:54 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys I started to play with sorting a bit Morphic :) So I would like to create a new Package Morphics-Widgets with the following contents. Morphic-Widgets-Basic SimpleSwitchMorph MulticolumnLazyListMorph SimpleButtonMorph LazyListMorph IconicButton ThreePhaseButtonMorph CalendarMorph Morphic-Widgets-Pluggable PluggableTabButtonMorph PluggableButtonMorph PluggableTextMorph PluggableMultiColumnListMorph PluggableTextMorphWithLimits PluggableTabBarMorph PluggableListMorph Morphic-Widgets-NewList NewList NewListRenderer NewListAdapter Morphic-Widgets-Tab Morphic-Widget-MorphTreeWidget Morphic-Widget-MorphTreeWidget-Pagination I would promote Morphic-Base-ProgressBar - Morphic-ProgressBar So what do you think? -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Please try to reproduce this bug
I just tried on Windows with: http://files.pharo.org/platform/Pharo2.0-win.zip and it works fine. Doru On Mon, Oct 7, 2013 at 11:04 AM, Goubier Thierry thierry.goub...@cea.frwrote: In short: does not happens if you use the get.pharo.org vm. Happens if you use the ubuntu pharo ppa. (ubuntu 13.04 64bits) Thierry Le 07/10/2013 10:12, Damien Cassou a écrit : Can you please try to reproduce this bug: 1- Open a fresh Pharo 2.0 2- Open Monticello 3- Select the package AST-Core 4- Click browse you get a PharoV20.sources does not exist. error message. You can't escape. Please write your findings in https://pharo.fogbugz.com/f/**cases/11803/PharoV20-sources-** does-not-exist-when-browsing-**with-Monticellohttps://pharo.fogbugz.com/f/cases/11803/PharoV20-sources-does-not-exist-when-browsing-with-Monticello . For me, it looks like the problem is in MCPackagesnapshot -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- www.tudorgirba.com Every thing has its own flow
