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

Re: [Pharo-dev] Pharo 4 and Roassal

by Stephan Eggermont

On 19-06-15 07:11, Alejandro Infante wrote: > Hi, > I did that because when using: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Gofer it > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > configurationOf: 'Roassal2'; > loadStable > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > It was installing 1.52 even though the stable version of Roassal was 1.12. > Instead if I used: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I was getting the right version (1.12). Gofer>>loadStable does not use the ConfigurationOfRoassal2 class>>loadStable (which is undefined, but many configurations define as self project load: #stable but loadVersion: #stable, which uses the latest version marked #stable. So yes, that is something you'd want to fix in place. And warn about on the mailing list. In this version 1.12 then we see that Roassal is tightly coupled to an old version of GlamourCore. So either ConfigurationOfRoassal2 needs to add a new #stable version every time GlamourCore #stable for Pharo 4 is updated, or it should depend on GlamourCore #stable. And ConfigurationOfGlamourCore has actually the same problem, as #stable currently depends on an old version of Rubric. So that should have been one or two versions more. And please note that this is for the released Pharo 4, where we are only supposed to backport important fixes. I strongly suggest to make ConfigurationOfGlamourCore #stable depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. Depending on #stable instead of #release1 or so works out ok here as long there is not supposed to be a new release for Pharo 4. Stephan

June 19, 2015

GitFileTree dependencies

by Yuriy Tymchuk

Hi, when loading GitFileTree in Pharo 5, I get: This package depends on the following classes: StringHolder You must resolve these dependencies before you will be able to load these definitions: CrLfFileEditor â¦ Does anybody know if this was caused by any recent changes? Uko P.S. we should add some mechanics to report dependency issues at CI server. Because when one loads Moose (for example) from scratch, he will encounter dependency issues, but as most of people who work on Moose download the ready-made image from CI, itâs not a visible problem.

June 19, 2015

Re: [Pharo-dev] Pharo 4.0 crash

by Sabine Manaa

Hi Max, ok I will do that. Thanks. Sabine 2015-06-19 10:07 GMT+02:00 Max Leske [via Smalltalk] < ml-node+s1294792n4833171h96(a)n4.nabble.com>: > > On 19 Jun 2015, at 09:31, Sabine Manaa <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4833171&i=0>> wrote: > > Hi, > > I have crashes from time to time. Are they useful for you? > > > yes, provided that they occur during ânormal useâ, i.e. if youâre not > doing advanced stuff, or simply running out of memory or running infinite > loops. > > If yes, where is the vm-dev list? > > > You can register for the vm-dev list here: > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > > If you submit a crash report, please add a description (as detailed as > possible) of what you have been doing. If you can reproduce the crash > consistently, that would be even better. In that case please list the steps > necessary to reproduce. > > Cheers, > Max > > > Regards > Sabine > > > > -- > View this message in context: > http://forum.world.st/Pharo-4-0-crash-tp4832475p4833169.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Pharo-4-0-crash-tp4832475p4833171.html > To unsubscribe from Pharo 4.0 crash, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Pharo-4-0-crash-tp4832475p4833187.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 19, 2015

[ANN] NeoConsole

by Sven Van Caekenberghe

Hi, NeoConsole is a small, standalone package that offers a command line (a.k.a. a REPL) interface to a headless Pharo image. It contains a number of extendable commands and metrics that allow you to execute arbitrary Pharo code for result (introspection and debugging) or side effect (to manipulate the live, running image). There is a history mechanism, you can refer to previous evaluation results and there is a primitive describe mechanism (like a one level inspect). The metrics system allows you to consult a number of predefined values. There is decent error handling. Here is a screencast showing how this feels in practice: https://www.youtube.com/watch?v=tAtYff6_X_4 The movie shows how to start from scratch, downloading Pharo, installing NeoConsole, running a headless image with the REPL installed in the background. Next, an HTTP server is added to the image and later a specific response is added as well. (You can speed up the movie, if you want). Obviously this has been done before, and this is not the definitive solution in this area. For example, readline support (allowing you to edit your input) would be fantastic. A true command line inspector and debugger would be super as well. These are standard features in Lisp and would be totally possible in Pharo too. I just needed this for myself, liked the result and thought it would be worth sharing. Sven PS: Security warning: this service opens up your image for access to those with access to your local network (i.e. those logged in to your machine), without any further authenication, allowing them to do absolutely anything. Think and make sure that you know what you are doing.

June 19, 2015

Re: [Pharo-dev] Pharo 4.0 crash

by Max Leske

> On 19 Jun 2015, at 09:31, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi, > > I have crashes from time to time. Are they useful for you? yes, provided that they occur during ânormal useâ, i.e. if youâre not doing advanced stuff, or simply running out of memory or running infinite loops. > If yes, where is the vm-dev list? You can register for the vm-dev list here: http://lists.squeakfoundation.org/mailman/listinfo/vm-dev <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev> If you submit a crash report, please add a description (as detailed as possible) of what you have been doing. If you can reproduce the crash consistently, that would be even better. In that case please list the steps necessary to reproduce. Cheers, Max > > Regards > Sabine > > > > -- > View this message in context: http://forum.world.st/Pharo-4-0-crash-tp4832475p4833169.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 19, 2015

Re: [Pharo-dev] Pharo 4.0 crash

by Sabine Manaa

Hi, I have crashes from time to time. Are they useful for you? If yes, where is the vm-dev list? Regards Sabine -- View this message in context: http://forum.world.st/Pharo-4-0-crash-tp4832475p4833169.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 19, 2015

Re: [Pharo-dev] Wrong parent in RBProgramNode after a #copy

by Marcus Denker

> On 18 Jun 2015, at 21:19, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > Ah, I'm sorry. Pharo is actually file, i.e., sets parent properly on > copy. I checked source of some methods but it's actually done > in others. > > Sorry for the noise! > The note with the blocks is correct, thoughâ¦ it is on my list to get rid of OCKeyedSet. (I reduced it already to just one use) Marcus

June 19, 2015

[pharo-project/pharo-core]

by GitHub

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

June 19, 2015

[pharo-project/pharo-core] ff672b: 50122

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ff672babb35487233ee6022ae91406bcbc1379e7 https://github.com/pharo-project/pharo-core/commit/ff672babb35487233ee6022a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-19 (Fri, 19 Jun 2015) Changed paths: A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/README.md A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/class/example/example.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/definition.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing pattern/ensureSafePattern_.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing pattern/pattern.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing pattern/updateList.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing pattern/whenPatternChanged_.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing/ghostString.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing/ghostString_.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing/initialRootItems.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing/patternModel.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/accessing/rootItems_.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/initialization/initialize.st A Morphic-Widgets-Tree.package/FilteredMorphTreeModel.class/instance/view/defaultDialogMorphIn_.st M Morphic-Widgets-Tree.package/MorphTreeListManager.class/instance/selection change/selectedItems_.st M Morphic-Widgets-Tree.package/MorphTreeModel.class/instance/dialog/dialogWindowIn_title_selectedtems_.st M Morphic-Widgets-Tree.package/MorphTreeModel.class/instance/selecting/selectItems_.st A Morphic-Widgets-Tree.package/MorphTreeModel.class/instance/view/defaultDialogMorphIn_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50121.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50122.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50121.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50122.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50122 15801 MorphTreeMorph improvement https://pharo.fogbugz.com/f/cases/15801 http://files.pharo.org/image/50/50122.zip

June 19, 2015

Re: [Pharo-dev] Pharo 4 and Roassal

by Alejandro Infante

Hi, About the current problem, I have found that Roassal2 current stable version depends on GlamourCore version 3.1.4, which depends on Rubric version 1.2.14 (the actual version that Metacello canât find) which use 3.1-baseline. Indeed this version is not visible from ConfigurationOfGlamourCore>>3.1-baseline (http://www.smalltalkhub.com/mc/AlainPlantec/Rubric/main <http://www.smalltalkhub.com/mc/AlainPlantec/Rubric/main>), but it is visible from ConfigurationOfGlamourCore>>3.2-baseline (http://www.smalltalkhub.com/mc/Pharo/Rubric/main <http://www.smalltalkhub.com/mc/Pharo/Rubric/main>) So I donât know if it is better to change GlamourCore version 3.1.4 to use 3.2-baseline (and change the history) or create a new version that use the new baseline, which involves to change all the projects that depends on version 3.1.4 of GlamourCore. Also I do not own the configuration of GlamourCore and I donât know either about Glamour dependencies, so I will not touch it. But this information should be useful to someone who knows about Glamour. Cheers, Alejandro > On Jun 19, 2015, at 2:11 AM, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: > > Hi, > I did that because when using: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Gofer it > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > configurationOf: 'Roassal2'; > loadStable > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > It was installing 1.52 even though the stable version of Roassal was 1.12. > Instead if I used: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I was getting the right version (1.12). > > Then looking the commit numbers loaded in 1.51 I realized that it was 1.5.1, but was never fixed and fixing it solves the problem. > > I was hoping to do more experiments before reporting it to the mailing list, but I was in a hurry because Roassal was being loaded incorrectly for everyone that tried to load the stable version in a Pharo4.0 image. > > About the people that was relying of 1.51 and 1.52 version name, Iâm deeply apologized for the troubles I may have caused, but the Roassal versions were inconsistently defined and I did not found any way to solve that cleanly. Even though I do not know how this can affect the loading of Roassal stable version now (that was 2 weeks ago) and considering that Roassal does not depends directly on Rubric. > > Cheers, > Alejandro > > PS: I would appreciate if someone can point a better way to handle the issue with version 1.51 and 1.52 of Roassal2 and hope nobody face any problem with it, because we have not received any complains about it (yet). > >> On Jun 18, 2015, at 6:49 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> Because I do not see how a version can be removed. >> Configuration is version-less so if you can remove it there, or just change it... e.g. >> >> ~~~~~ >> Name: ConfigurationOfRoassal2-AlejandroInfante.37 >> Author: AlejandroInfante >> Time: 2 June 2015, 6:48:30.901514 pm >> UUID: 6257332e-2902-4cd0-ba0f-0d9180ac6e65 >> Ancestors: ConfigurationOfRoassal2-AlejandroInfante.36 >> >> Fixed version 1.51 and 1.52 to be 1.5.1 and 1.5.2. >> ~~~~ >> >> Not sure if it is good approach, but even in git you can remove tags/versions and rewrite history, but if you know about it it's rarely a problem. >> >> Peter >

June 19, 2015