Re: [Pharo-dev] CI Server still down...
Le 20 févr. 2015 à 11:22, Tudor Girba a écrit : Thank you for keeping an eye on this. Just a note: while the servers being down can induce some frustration we should remember that INRIA is very kind to offer this support for our community. So, thanks for all the hard work that happens behind the scene! And this upgrade is the first mandatory step to enable OS X slaves on the Inria CI service. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] I just crashed sthub
On 19/02/15 14:31, Esteban Lorenzano wrote:
is restored… but I couldn’t applied the change I wanted… maybe tomorrow :)
On 19 Feb 2015, at 14:24, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
Thank you Esteban.
On 19 Feb 2015, at 14:18, Esteban Lorenzano esteba...@gmail.com wrote:
is temporal
and for the better good.
please, be patient :)
Always asking for the impossible...
In the last green build of the 3.0 SmalltalkHub image I cannot load your
changes. Some compiler bug.
- ShTeamsHandlersearchTeamNamed: should use #name instead of #username
searchTeamNamed: aString
get
path: '?term={aString}'
produces: 'text/json'
^self renderJson: [
(ShTeam select: {'name' - {
'$regex' - aString.
'$options' - 'i' } asDictionary } asDictionary)
collect: #name ]
The configuration should use #release versions of
Seaside/Magritte/Grease. We support multiple versions on a platform.
http://smalltalkhub.com/hub/projects?term=c
VOMongoError: Lazy reference not found ShTeam: OID(3583374428)
Cheers,
Stephan
Re: [Pharo-dev] I just crashed sthub
On 20 Feb 2015, at 12:21, Stephan Eggermont step...@stack.nl wrote:
On 19/02/15 14:31, Esteban Lorenzano wrote:
is restored… but I couldn’t applied the change I wanted… maybe tomorrow :)
On 19 Feb 2015, at 14:24, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
Thank you Esteban.
On 19 Feb 2015, at 14:18, Esteban Lorenzano esteba...@gmail.com wrote:
is temporal
and for the better good.
please, be patient :)
Always asking for the impossible...
In the last green build of the 3.0 SmalltalkHub image I cannot load your
changes. Some compiler bug.
I’m aware, fixing now.
- ShTeamsHandlersearchTeamNamed: should use #name instead of #username
I never touched anything like that :)
searchTeamNamed: aString
get
path: '?term={aString}'
produces: 'text/json'
^self renderJson: [
(ShTeam select: {'name' - {
'$regex' - aString.
'$options' - 'i' } asDictionary } asDictionary)
collect: #name ]
The configuration should use #release versions of Seaside/Magritte/Grease. We
support multiple versions on a platform.
http://smalltalkhub.com/hub/projects?term=c
VOMongoError: Lazy reference not found ShTeam: OID(3583374428)
again… no idea and nothing to do with my changes…
So… are you reporting previous bugs? I do not understand :P
Esteban
Cheers,
Stephan
Re: [Pharo-dev] I just crashed sthub
On 20/02/15 12:26, Esteban Lorenzano wrote: On 20 Feb 2015, at 12:21, Stephan Eggermont step...@stack.nl wrote: In the last green build of the 3.0 SmalltalkHub image I cannot load your changes. Some compiler bug. I’m aware, fixing now. A, good. - ShTeamsHandlersearchTeamNamed: should use #name instead of #username I never touched anything like that :) I know. http://smalltalkhub.com/hub/projects?term=c VOMongoError: Lazy reference not found ShTeam: OID(3583374428) again… no idea and nothing to do with my changes… So… are you reporting previous bugs? I do not understand :P I'm trying to update DeprecationFinder. It seems to work as is, just loading in a Moose 5.1. It starts with users and asks them for their projects, but that means it misses team projects (like Pharo, Seaside, Magritte, Moose...). I wanted to start from teams now, and found I couldn't. Finding a team doesn't work because of the username/name bug and using a regex often results in the mongo error. And of course I need to check in SmalltalkHub to see how to access this. Stephan
Re: [Pharo-dev] untypeable key combination
On 19 Feb 2015, at 10:19, Nicolai Hess nicolaih...@web.de wrote: Fogbugz issue 14936 and slice in inbox After loading this slice, there are still many references to the (now) obsolete class KMUntypeableSingleKeyCombination. I tried to remove these references with the following code : NECPreferences popupShowWithShortcut: nil. KMSingleKeyCombination reset. KMSpecialCharSingleKeyCombination reset. KMRepository reset. But they arent removed. Anyone knows how to re-init all users of KMUntypeableSingleKeyCombination ? Very strange… using “explore pointers” with the old inspector, it shows lots of instances… I sadly have no time to now look deeper, but the pointer explorer should be a way to find who holds onto them… Marcus
[Pharo-dev] CI Server still down...
Hi, CI Servers are still down. Until they are up we can not do any integration nor run the automatic check on submitted things. Marcus
Re: [Pharo-dev] CI Server still down...
Thank you for keeping an eye on this. Just a note: while the servers being down can induce some frustration we should remember that INRIA is very kind to offer this support for our community. So, thanks for all the hard work that happens behind the scene! Cheers, Doru On Fri, Feb 20, 2015 at 11:03 AM, Marcus Denker marcus.den...@inria.fr wrote: Hi, CI Servers are still down. Until they are up we can not do any integration nor run the automatic check on submitted things. Marcus -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Spec terminology: renaming some terms
However, reflecting all of this in the name, ComposableModel, makes it unclear what it is for. From Seamless Composition and Reuse of Customizable User Interfaces with Spec ( http://rmod.lille.inria.fr/archives/papers/Ryse13a-SCICO-Spec.pdf ) UI Element: an interactive graphical element displayed as part of the Graphical User Interface. UI Model: an object that contains the state and behavior of one or several UI elements. Widget: the union of a UI Element and its UI model. My understanding was that Element is Morphic, Model is Spec and Widget is an adapter? -- But in the end once you start using it you know what to look for (= 10 minutes after reading tutorial) does it really make that much difference? It is just a subclass. From my point having clean and well organized protocols is more important, because you will end up interacting with those order of magnitude more, and if there is method in unexpected protocol... well then I might as well use --show all protocols--. Also whenXYChanged methods are not so nice (those have been mentioned previously).
Re: [Pharo-dev] Spec terminology: renaming some terms
On 20 Feb 2015, at 12:23 , Nicolai Hess nicolaih...@web.de wrote: 2015-02-19 23:24 GMT+01:00 Johan Fabry jfa...@dcc.uchile.cl mailto:jfa...@dcc.uchile.cl: The problem is that people are confused by the term Model, so they will also be confused by Logic. I want to remove the confusion and make clear that it is a user interface (and that it is composable by default) - ComposableUI. It could also be ComposableUserInterface but we do not win anything by that name, as UI is a standard acronym + we would have to type more when subclassing it. So I prefer ComposableUI. But this *is* a model, not a UI. Yes a model for the UI, but still, the real UI-View is what comes through the Spec interpreter. UI sounds like the whole user interface, but Specs ComposableModels are meant as building blocks. UI-Model - WidgetAdapter - Widget/View. I would prefer (in this order): 1. ComposableModel (because this is the current name) 2. ComposableWidgetModel (widget: a brick or part of an UI) 3. ComposableUIModel 4. ComposableUI I am not fully against 4., because it is the goal of spec to build reuseable UIs. For example for a Spec based ListSelectionDialog we can reuse the whole component, not only the model, not only the view, but the whole component with interaction between the list and other controls. But I would prefer ComposableWidgetModel, because a Widget (button/textfield/list) is the smallest unit of a user interface representable with Spec. If the goal is avoiding confusion to data model classes, why not just use Spec in place of Model? It reflects the framework name, and is fairly descriptive in that the classes are neither the actual widgets, nor the models that hold data, but a specification of how they are composed and wired together. Cheers, Henry
Re: [Pharo-dev] [FIX]: Issue 4795: Horizontal wheel
Bueller? I think the devs here are perhaps *slightly* more busy than the drooling teenagers in that scene... :) -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Re: [Pharo-dev] Why was #asLegalSelector removed?
On 19/02/15 18:43, Damien Pollet wrote: I think it would make sense to publish a configuration for DeprecationFinder in the configuration browser. Does it work on any Pharo image, or is it written on top of Moose ? I'm trying to see if it still runs atm. Looking good in a Moose 5.1. 50 MB of package cache, 1250 monticello packages and counting. Hmm, found a bug in MooseMonticelloHTTPImporter. VHDL-cipt.24.mcz has a method name ending in _class and that confuse resolveInstanceSide: aNamedEntity I deliberately didn't put this in the configuration browser as running this code without the delay in getAllFrom:thenDo: performs a DOS attack. It also takes a lot of time to run, getting all packages and just creates a data structure that is easy to inspect. DeprecationFinder default findAllUsers just starts downloading and parsing everything. I never bothered creating a UI, as the GTInspector is good enough. Stephan
[Pharo-dev] [jenkins] 30 issues for review
Hi, People are busy submitting fixes and improvements.. we should not forget to give them feedback. There are a lot if issues that needs reviews… 6 where the monkey ran (or can not run): https://pharo.fogbugz.com/f/filters/45/Review and 26 waiting for the monkey that is down due to CI: https://pharo.fogbugz.com/f/filters/36/Fixed-to-Review Marcus
[Pharo-dev] How to get rid of GT-Playground
instances ? If you open a fresh image and change the setting to use the old workspace open a workspace and execute: GTPlayground allInstances size - 1 There is already one instance. I tried to get rid of this instance but I couldn't find a way. I think this instance is responsible for issue 14928 https://pharo.fogbugz.com/default.asp?14928: SystemNavigation default obsoleteClasses - an Array(AnObsoleteGLMPageScroller AnObsoleteGLMPagerScrollMorph) And this in turn, is repsonsible for undeleteable references to AnObsoleteKMUntypeableSingleKeyCombination. I need this for issue 14936 https://pharo.fogbugz.com/default.asp?14936 any idea? nicolai
[Pharo-dev] MCVersionInfo: 10% of the image
Hi, The current Pharo4 contains *a lot* of MCVersionInfo instances. MCVersionInfo allInstances size 11095 The hold on to strings, Date, UUID… a lot of stuff. All in all, this is around 10% of the current image. If you do MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. you image is a couple of MB smaller. In the past, when this information started to be 8MB, we did that. With the bad effect that we can not merge anymore across this boundary: we kill the past. Now this information is of course continained in the last MCZ file, too (all of them contain the complete history…) So would the following work? - we set the “ancestors” of MCVersionInfo to #reload - the accessor, when it sees #reload, takes the name, deduces from that the package, and goes to the repo to load the ancestry info from the MCZFile. This means that e.g when saving a MCZFile, it would first re-create history info and then save it completely (like now), yet someone who just uses the system would never need to have this info in the image. Marcus
Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials
stepharo wrote I was thinking that we could use Author Ah, yes. That might be a good place. We have KeyChain in the image. I wonder what the status of that is. It seems like it was designed for this purpose... - Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-tp4806424p4806667.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Why was #asLegalSelector removed?
As you know, I love cleaning ;) But... stepharo wrote https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/StringCleaning.md What enlightenment am I supposed to gain from candidates for removal... asLegalSelector, and later Done: candidates for removal... asLegalSelector. I still understand nothing of the rationale. stepharo wrote This code is bogus and shitty. And useful ;) (as evidenced by this thread). Okay, it's limited, but what's better - having users roll their own every time? For now, I'll package it with my code, but I think we should add it back, maybe with a method comment to clarify that it creates a unary selector only... Bring back #asLegalSelector https://pharo.fogbugz.com/default.asp?14969 Fix in inbox: SLICE-Issue-14969-Bring-back-asLegalSelector-SeanDeNigris.1 - Cheers, Sean -- View this message in context: http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427p4806671.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] How to get rid of GT-Playground
Interesting! I sometimes notice the phenomenon of image growing and I suspected it has to do with the playground/inspector. We should investigate a memory leak related to announcements. I will try to look into this. Could you open an issue? This is a must fix for Pharo 4. Cheers, Doru On Fri, Feb 20, 2015 at 2:17 PM, Nicolai Hess nicolaih...@web.de wrote: instances ? If you open a fresh image and change the setting to use the old workspace open a workspace and execute: GTPlayground allInstances size - 1 There is already one instance. I tried to get rid of this instance but I couldn't find a way. I think this instance is responsible for issue 14928 https://pharo.fogbugz.com/default.asp?14928: SystemNavigation default obsoleteClasses - an Array(AnObsoleteGLMPageScroller AnObsoleteGLMPagerScrollMorph) And this in turn, is repsonsible for undeleteable references to AnObsoleteKMUntypeableSingleKeyCombination. I need this for issue 14936 https://pharo.fogbugz.com/default.asp?14936 any idea? nicolai -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Why was #asLegalSelector removed?
Damien I decided that living is about mistakes so I will not stress and continue to improve the platform. And from time to time I will do a mistake and we will fix it. I prefer to die because I have moved than because I feared to move because at the end I will die. Stef Le 19/2/15 18:43, Damien Pollet a écrit : I'm usually extremely apprehensive of changing code I don't own, to the point I — sadly — contribute nearly nothing to Pharo. Now, cleaning the platform — and in this case, by cleaning, I really mean hazmat suits, industrial grade acid, and flame throwers — is going to break things. I'm all for a process to help others follow such changes, but if we want a process to work, it has to be even simpler than not having a process. In any case I don't want to have to stress over touching platform code. I think it would make sense to publish a configuration for DeprecationFinder in the configuration browser. Does it work on any Pharo image, or is it written on top of Moose ? About #asComment : since class comments are free text, any string will do and there is no escapement sequences to enforce. Maybe ideally we would have string un/escaper objects responsible for translating between free text and and specific encodings (comments, strings, regexes, URLs…) On 19 February 2015 at 15:05, stephan step...@stack.nl mailto:step...@stack.nl wrote: The way this was handled can be improved. It is sometimes difficult for us not in Lille to find out what is going on. - a specific issue name helps us notice what changes - check where code is used. DeprecationFinder works for that (and should add more repos and team projects). And a specific one: the rename from #asSmalltalkComment to #asComment is problematic. There are 2 kinds of thing casually known as comments: the comment text in a method, and the class comment. The method name should reflect that. Stephan -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Re: [Pharo-dev] #fromFileNamed: seems too UNIX-y
Yes. But convenience and clean separation of responsibilities sometimes conflict (I mean, do all these object even have to know about files ?) On 20 Feb 2015, at 23:42, Sean P. DeNigris s...@clipperadams.com wrote: Now that we have a beautiful File API, would it make sense to use real file objects everywhere instead of string passing? - Cheers, Sean -- View this message in context: http://forum.world.st/fromFileNamed-seems-too-UNIX-y-tp4806748.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] #fromFileNamed: seems too UNIX-y
Sven Van Caekenberghe-2 wrote But convenience and clean separation of responsibilities sometimes conflict (I mean, do all these object even have to know about files ?) Good point! But what do we do? The logic is too complicated for users to roll-their-own... It would be nice to have a collaborating role like dataSource, but the problem is that there are no specific FileReference sub-types and we don't want to cloud up FileReference on the other side... - Cheers, Sean -- View this message in context: http://forum.world.st/fromFileNamed-seems-too-UNIX-y-tp4806748p4806763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Spec terminology: renaming some terms
On Feb 20, 2015, at 12:07, Sean P. DeNigris s...@clipperadams.com wrote: Henrik Sperre Johansen wrote If the goal is avoiding confusion to data model classes... Do we even need Composable in the name? This is relevant from a where we came from standpoint, but to a new user, maybe it can be documented without adding 10 characters to the class name… Sure, we could consider that … do you have any concrete suggestions? --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] MCVersionInfo: 10% of the image
Chris, didn't you do something about this in Squeak? It would be nice to keep consistent if possible... Eliot (phone) On Feb 20, 2015, at 6:41 AM, Marcus Denker marcus.den...@inria.fr wrote: Hi, The current Pharo4 contains *a lot* of MCVersionInfo instances. MCVersionInfo allInstances size 11095 The hold on to strings, Date, UUID… a lot of stuff. All in all, this is around 10% of the current image. If you do MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. you image is a couple of MB smaller. In the past, when this information started to be 8MB, we did that. With the bad effect that we can not merge anymore across this boundary: we kill the past. Now this information is of course continained in the last MCZ file, too (all of them contain the complete history…) So would the following work? - we set the “ancestors” of MCVersionInfo to #reload - the accessor, when it sees #reload, takes the name, deduces from that the package, and goes to the repo to load the ancestry info from the MCZFile. This means that e.g when saving a MCZFile, it would first re-create history info and then save it completely (like now), yet someone who just uses the system would never need to have this info in the image. Marcus
Re: [Pharo-dev] Spec terminology: renaming some terms
Henrik Sperre Johansen wrote If the goal is avoiding confusion to data model classes... Do we even need Composable in the name? This is relevant from a where we came from standpoint, but to a new user, maybe it can be documented without adding 10 characters to the class name... - Cheers, Sean -- View this message in context: http://forum.world.st/Spec-terminology-renaming-some-terms-tp4806486p4806677.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Spec terminology: renaming some terms
Do we even need Composable in the name? Why not just SpecModel or SpecUIModel? Btw there's also DynamicComposableModel.
Re: [Pharo-dev] development workflow for GTools (GToolkitCore)
Hi, On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess nicolaih...@web.de wrote: 2015-02-08 13:01 GMT+01:00 Tudor Girba tu...@tudorgirba.com: Hi Nicolai, On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess nicolaih...@web.de wrote: 14850 https://pharo.fogbugz.com/default.asp?14850 Integrate GTools #development From this version onwards the development version should be integrated. Is this a good idea? Does the #development version always include *all* the latest changes, because after Andrei opened 14866 https://pharo.fogbugz.com/default.asp?14866 Integrate GTools (which got integrated in 40475) I uploaded some changes for issue 14608 https://pharo.fogbugz.com/default.asp?14608 ClassTest#testClassRespectsPolymorphismWithTrait failing due to Spotter methods I set the status to Fix Review needed, but my changes are integrated in 40475 too! I think that in the current situation, it is actually a good idea. And yes, the integration does include all latest versions of GT-related packages. Before changing to development, we required a stable release for the integration. That implied: 1. creating a stable release and 2. integrating it in the Pharo through a separate issue. Yet, in GT we all work on the very latest version, and creating a stable release is somewhat artificial given the speed at which things are changing now. Creating the stable version also led to delays between a fix in GT and an integration in Pharo (sometimes measured in weeks). It still takes weeks. the last GToolkitCore integration was 3 weeks ago. That's because of two reasons: (1) we did some changes that took longer, and (2) by the time we were ready to commit the jenkins went off. So, this time it is not so representative. We do want this to happen faster. So, in the case of GT requiring the stable release did not provide any added value, but it has the negative consequence of delays. I am not satisfied with the way external packages are handled. 1. if there is not one slice/changeset per issue, it is even less likely someone will review the changes. 2. you don't know who works when on a issue. They are solved in a bulk. 3. a new configuration might not only includes bugfixes but new features as well. 4. often we have unbound globals / undeclared references or other test failures. Can we use the build server for those external projects (like GToolkitCore, Athens, TxText), and that if a project makes a new configuration, it uses the same issue validator for loading and testing that configuration? We already have a GToollkitCore job, but it only runs the GT tests. Perhaps this is not enough? https://ci.inria.fr/moose/job/gtoolkitcore/ It would be nice if it runs some of the image validation tests ReleaseTest ClassTest BehaviorTest ... It now runs the ReleaseTest. We can add the ClassTest and BehaviorTest. What other tests should we add? Doru That way we can we see early enough, if GT-Extensions will break some validation rules (unresovled externals / Obsolete classes / Polymorphism Trait/Class) But, could the Monkey not be able to run all tests before an integration of the development version? I don't know if the Monkey can load Configurations. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [FIX]: Issue 4795: Horizontal wheel
ccrraaiigg wrote Bueller? I think the devs here are perhaps *slightly* more busy than the drooling teenagers in that scene... :) Hopefully, our days with Smalltalk are more like borrowing the Ferrari for an adventure ;) - Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Issue-4795-Horizontal-wheel-tp4805005p4806674.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] [Pharo4] Action needed: Issue tracker at 684 issues
Hello, The issue tracker has an ever growing list of issues. We do a lot (e.g. last 7 days we closed 55), but nevertheless, as some point this is so much that issues are just not being acted on because there are so many. Therefore: - Please check *ALL* the issue that you submitted. Have they been fixed? Are they really so important that they should take away attentions from other things? - Check all the issues that you where involved in. With 684 issues, there is *NOBODY* that will look at your issue to fix trivalities (e.g. Monkey failed due to a system problem) the than you. - Try to push some issue that you think is important. Even if you can’t do anything, maybe you can convince others to help you to fix this? Marcus
Re: [Pharo-dev] development workflow for GTools (GToolkitCore)
2015-02-08 13:01 GMT+01:00 Tudor Girba tu...@tudorgirba.com: Hi Nicolai, On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess nicolaih...@web.de wrote: 14850 https://pharo.fogbugz.com/default.asp?14850 Integrate GTools #development From this version onwards the development version should be integrated. Is this a good idea? Does the #development version always include *all* the latest changes, because after Andrei opened 14866 https://pharo.fogbugz.com/default.asp?14866 Integrate GTools (which got integrated in 40475) I uploaded some changes for issue 14608 https://pharo.fogbugz.com/default.asp?14608 ClassTest#testClassRespectsPolymorphismWithTrait failing due to Spotter methods I set the status to Fix Review needed, but my changes are integrated in 40475 too! I think that in the current situation, it is actually a good idea. And yes, the integration does include all latest versions of GT-related packages. Before changing to development, we required a stable release for the integration. That implied: 1. creating a stable release and 2. integrating it in the Pharo through a separate issue. Yet, in GT we all work on the very latest version, and creating a stable release is somewhat artificial given the speed at which things are changing now. Creating the stable version also led to delays between a fix in GT and an integration in Pharo (sometimes measured in weeks). It still takes weeks. the last GToolkitCore integration was 3 weeks ago. So, in the case of GT requiring the stable release did not provide any added value, but it has the negative consequence of delays. I am not satisfied with the way external packages are handled. 1. if there is not one slice/changeset per issue, it is even less likely someone will review the changes. 2. you don't know who works when on a issue. They are solved in a bulk. 3. a new configuration might not only includes bugfixes but new features as well. 4. often we have unbound globals / undeclared references or other test failures. Can we use the build server for those external projects (like GToolkitCore, Athens, TxText), and that if a project makes a new configuration, it uses the same issue validator for loading and testing that configuration? We already have a GToollkitCore job, but it only runs the GT tests. Perhaps this is not enough? https://ci.inria.fr/moose/job/gtoolkitcore/ It would be nice if it runs some of the image validation tests ReleaseTest ClassTest BehaviorTest ... That way we can we see early enough, if GT-Extensions will break some validation rules (unresovled externals / Obsolete classes / Polymorphism Trait/Class) But, could the Monkey not be able to run all tests before an integration of the development version? I don't know if the Monkey can load Configurations. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] MCVersionInfo: 10% of the image
Le 20/02/2015 15:41, Marcus Denker a écrit : Hi, The current Pharo4 contains *a lot* of MCVersionInfo instances. MCVersionInfo allInstances size 11095 The hold on to strings, Date, UUID… a lot of stuff. All in all, this is around 10% of the current image. If you do MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. you image is a couple of MB smaller. In the past, when this information started to be 8MB, we did that. With the bad effect that we can not merge anymore across this boundary: we kill the past. You can still merge across that boundary, but you need to do it in git, not in Monticello. Now this information is of course continained in the last MCZ file, too (all of them contain the complete history…) So would the following work? - we set the “ancestors” of MCVersionInfo to #reload - the accessor, when it sees #reload, takes the name, deduces from that the package, and goes to the repo to load the ancestry info from the MCZFile. This means that e.g when saving a MCZFile, it would first re-create history info and then save it completely (like now), yet someone who just uses the system would never need to have this info in the image. Yes, this could work. But I'll probably try a subclass of MCVersionInfo with a kind of lazy loading of the ancestry chain (in a weak array so that it gets eaten away if not used). And the weak array would ensure that you don't overuse memory without having to use become: Like that, on git, I could be faster and not write the whole ancestry at all. I just did something a bit reverse with MCDependencyVersion for GitFileTree: I added a MCResolvedDependencyVersion and it worked. Up to you. Thierry
Re: [Pharo-dev] MCVersionInfo: 10% of the image
Chris, didn't you do something about this in Squeak? It would be nice to keep consistent if possible... Yes, but no one liked it because it employed the Proxy design-pattern and requires a become. Perhaps if I'd gotten it perfect the first time it'd have been better-received. But, I didn't, and the ensuing backlash wiped out any motivation for me to fix it. Marcus' suggestion is more explicit, and so might be better received by the community. There's a tradeoff between the two designs: In my design, you have to make sure you get it right or the image could lock up. In Marcus' design, you have to sprinkle multiple checks for #reload in the code and make sure you get it right, or you might end up saving corrupt MCZ packages (e.g., with #reload as the ancestry). Either way, its a wasteful part of the design of MC that should be addressed. I'm partial to fixing the Proxy solution, but I'd be in favor of ripping it out and adopting a stable alternative from Pharo if it becomes available. Eliot (phone) On Feb 20, 2015, at 6:41 AM, Marcus Denker marcus.den...@inria.fr wrote: Hi, The current Pharo4 contains *a lot* of MCVersionInfo instances. MCVersionInfo allInstances size 11095 The hold on to strings, Date, UUID… a lot of stuff. All in all, this is around 10% of the current image. If you do MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. you image is a couple of MB smaller. In the past, when this information started to be 8MB, we did that. With the bad effect that we can not merge anymore across this boundary: we kill the past. Now this information is of course continained in the last MCZ file, too (all of them contain the complete history…) So would the following work? - we set the “ancestors” of MCVersionInfo to #reload - the accessor, when it sees #reload, takes the name, deduces from that the package, and goes to the repo to load the ancestry info from the MCZFile. This means that e.g when saving a MCZFile, it would first re-create history info and then save it completely (like now), yet someone who just uses the system would never need to have this info in the image. Marcus
