- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Trying to use Rubric in Nautilus ....

by Alain Plantec

Hello Franck, just changed shoutAboutToStyle: as follow: AbstractNautilusUI>>shoutAboutToStyle: aPluggableShoutMorphOrView âThe comments are not styled" ^ aPluggableShoutMorphOrView ~= commentTextArea and it seems to work. Now, pay attention that, with Rubric, this is the editing mode that is passed as argument (for aPluggableShoutMorphOrView). Here, a RubSmalltalkCodeMode. if you plan to use a Rubric also for the comments, then, normally shoutAboutToStyle: will not be sent because I guess a RubPlainTextMode will be used for the comment pane. This mode do not use shout. In that case the final version should be: AbstractNautilusUI>>shoutAboutToStyle: aPluggableShoutMorphOrView ^ true Cheers Alain > On 18 May 2015, at 14:41, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > Hi, > > With Alain's last commit of Rubric (205) we made a few changes to put Rubric in Nautilus. You can see thoses changes in the attached file. > As you can see there is no colors in the browser... Is RubScrolledTextMorph>>beForSmalltalkCode the good option ? I thought there would be just an option like aboutToStyle: true or something like that but there is not. I do not know if I missed something obvious or if I have to add the connection to RubShoutStylerDecorator. Any idea everyone ? > I am losing my eyes with uncolored code but I guess it is worth it. > > Thanks, > > Franck > > > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > From: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > CC: alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com> > Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... > Date: Thu, 14 May 2015 05:16:30 -0700 > > > > --PiÃ¨ce jointe du message transmise-- > Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... > From: alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com> > Date: Thu, 14 May 2015 14:16:16 +0200 > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > > done & committed > Cheers > Alain > On 14 May 2015, at 12:06, Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>> wrote: > > ahh, good remark :) > the menu stuff is not finished. > I do it now > thanks > Alain > > On 13 May 2015, at 18:09, Franck Warlouzet <franck.warlouzet(a)hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote: > > Hi alain > > thanks a lot! > This helps us a lot. We got nearly something working. We will produce a list of methods and changes we had to do. > see in the attached cs. > > Now > > lookupMenu > "default implementation of the algorithm that lookup the menu" > > | default | > default := [ self editingMode menu ]. > ^ self model > ifNil: [ default value ] > ifNotNil: [ :m | m menu ifNil: [ default value ] ] > > We add a new method in nautilus that creates a menu as follow > because m is our NautilusModel > > menu > ^ self sourceCodeMenu: MenuMorph new shifted: false. > > But I was wondering why m menu does not take into account the information we passed when we created the rubPluggable > > sourceTextArea := self textMorphClass > on: self > text: #sourceCodeFrom: > accept: #compileSource:notifying: > readSelection: #contentsSelectionFrom: > menu: #sourceCodeMenu:shifted:. > > I see that > RubEditingArea has a policy but we could find how we can improve RubPluggable to use the menu: > > > > > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > From: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > CC: alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com> > Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... > Date: Wed, 13 May 2015 07:26:15 -0700 > > > > --PiÃ¨ce jointe du message transmise-- > Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... > From: alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com> > Date: Wed, 13 May 2015 16:25:34 +0200 > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > > see Rubric-AlainPlantec.196 in the Rubric repo. > > Iâve added RubPluggableTextMorph and RubPluggableTextMorphExample. > Need to be polished certainly but it should facilitate the integration of Rubric in Nautilus. > > cheers > Alain > > On 12 May 2015, at 22:45, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > For fun I put the following trace in > > sourceCodeFrom: aTextMorph > Transcript show: '.'. > ^ self sourceCode > > And in general this method is invoked three times instead of one :) > > > > Before asking we read all the examples and I saw that selector: is used to communicate and update the code pane. > > (UIManager default newAutoAcceptTextEntryFor: self > get: #selector > set: #selector: > class: String > getEnabled: #haveClassName > help: 'Enter a selector' translated > entryCompletion: entryCompletion) > acceptOnCR: false; > ghostText: 'Selector'; > withDropListButton; > > > I think this is only for the drop down list. > > What I meant is that I could use set: and pass the selector to be invoked by the dropdown when the drop down is selected. > And it will notify self with the selector: selector. So we could sepcify any selector (ie I can register to the drop box and say call me once you are set). > > > In RubMethodEditingExample>>#selector: > it calls the update explicit > self updateCodeWith: (cls sourceCodeAt: selector) > and updateCodeWith: sets the text on the text model. > > > > > Now my problem (and may be there is not solution) is how can I connect from a pluggableListMorph to a RubScrollText > when the list does not generate announcement. > This is why I tried to pass via dependents or something like that. > > I will try to generate announcements but this is a lot more work and I do not know if it will work. > > Stef > > > > > > <glueRubNautilus.2.cs> > > > <Unnamed.cs>

May 18, 2015

[pharo-project/pharo-core] 0c77aa: 50049

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0c77aac8e97adf1d258ac772125041bcd6628980 https://github.com/pharo-project/pharo-core/commit/0c77aac8e97adf1d258ac772… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-18 (Mon, 18 May 2015) Changed paths: R Athens-Cairo.package/AthensCairoCanvas.class/instance/drawing text/setFont_.st R Athens-Cairo.package/AthensCairoPDFSurface.class/instance/private/newCanvas.st A Athens-Core.package/extension/BitmapFillStyle/instance/asAthensPaintOn_.st M Athens-Morphic.package/AthensParagraph.class/instance/as yet unclassified/secondarySelection_.st R Athens-Morphic.package/AthensWorldMorph.class/instance/world state/viewBox_.st R Athens-Morphic.package/AthensWrapWorldMorph.class/instance/drawing/fullDrawOnAthensCanvas_.st R Athens-Morphic.package/AthensWrapWorldMorph.class/instance/drawing/render.st M Athens-Morphic.package/extension/EllipseMorph/instance/asAthensShapeOn_.st M Athens-Morphic.package/extension/EllipseMorph/instance/drawOnAthensCanvas_.st A Athens-Morphic.package/extension/PolygonMorph/instance/adjustSegmentPointsForArrows.st A Athens-Morphic.package/extension/PolygonMorph/instance/asAthensCurvedOpenPathOn_.st A Athens-Morphic.package/extension/PolygonMorph/instance/asAthensCurvedPathOn_.st A Athens-Morphic.package/extension/PolygonMorph/instance/asAthensLinePathOn_.st A Athens-Morphic.package/extension/PolygonMorph/instance/asAthensPathOn_.st A Athens-Morphic.package/extension/PolygonMorph/instance/computeCurvedSegmentCtrlPoints.st A Athens-Morphic.package/extension/PolygonMorph/instance/drawArrowOnAthensCanvas_at_from_.st A Athens-Morphic.package/extension/PolygonMorph/instance/drawArrowsOnAthensCanvas_.st A Athens-Morphic.package/extension/PolygonMorph/instance/drawOnAthensCanvas_.st A Athens-Morphic.package/extension/PolygonMorph/instance/hasTwoColorDash.st A Athens-Morphic.package/extension/PolygonMorph/instance/setDashOnStroke_.st A Athens-Morphic.package/extension/PolygonMorph/instance/setSecondColorDashOnStroke_.st A ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version35_.st M Manifest-Core.package/extension/RPackage/instance/packageManifest.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50048.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50049.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50048.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50049.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50049 15557 New PackageManifests should be classes, not instances https://pharo.fogbugz.com/f/cases/15557 15556 use new athens configuration 3.5 https://pharo.fogbugz.com/f/cases/15556 http://files.pharo.org/image/50/50049.zip

May 18, 2015

[pharo-project/pharo-core]

by GitHub

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

May 18, 2015

Re: [Pharo-dev] Default package comment

by Sergio Fedi

> > Personally, I do not fear to change the comment implementation later. > > That's what Smalltalk is good at. > > +1. But the most difficult thing is not to change the implementation but all its usage. > if people start to use a feature and you change the way to use it after, it is more difficult to update all users of the feature. Problem is, this feature is not used now because it doesn't exist. Bottom line is: If the future usage problem is about what to put in the default comment, It's ok for me to change it however we decide. If the future usage problem is about what other metadata we put con the Manifest then it is irrelevant for this issue. > > preInstallComment > > postInstallComment > > what is that? if it is Smalltalk code to run before/after the installation, it should not be in the comment but in a separated method. > Pharo misses a package setUp and tearDown methods. These are comments relating to thing you have to be aware of before installing and after installing the package. For example, a behaviour changed on some objects. A new option on a menu. Another package that does not "get along" with this package. Things that are not code, but are relevant either before or after the loading of a package. > > authorshipText > > contactDescription > > creationDate > > lastUpdateDate > > This information is meta-information on a package and should not be lost in the package comment. Exactly. Except that when you can't put it anywhere else, it usually ends up in the comment. (my argument is: as long as you don't have anywhere else to put certain info, it's better to have it somewhere rather than nowhere, so you could suggest that in the default comment) > > My initial strategy was to have comments and then model the commonalities of all package comments away to the appropiate method/variable/data > > I already started to work on some specific package meta-data. > As I wrote before, for now, I store it in the PackageManifest because Monticello does not have a good support for meta-data. > But anyway, we could just see that as an "implementation details". > What I think is important is not to work directly with the PackageManifest but having an object manipulating it and able to answer to selectors like: > MyPackage>>description > MyPackage>>description: aText We are doing the same thing then. > I work on a spec widget to edit some package meta-data. > Maybe you could do the same to be able to present other meta-data than the package comment from Nautilus. It is more work and can just come for a second version. I think that will be necessary for sure. For now, it seems really easy and straightforward to show comments in Nautilus. It uses the same real state that class comments use. Other metadata, I'm not sure how it would work. That would fall more under the province of a PackageBrowser or something like that. Dolphin has this problem solved in a nice way (I don't know how other Smalltalks solve it) So, to clear thing up, what are you saying? 1 - Don't mention putting other information in the default package comment 2 - Make more methods for other metadata such as [...] 3 - Both, 1 and 2 4 - Other?

May 18, 2015

Metacello and #stable

by Andrei Chis

Hi, If I specify a stable version for a platform (spec for: #'pharo3.x' version: '3.0.6'.), shouldn't Metacello load that version? Concrete use-case: loading ConfigurationOfMoose in Pharo 3 - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 (spec for: #'pharo3.x' version: '3.0.6') Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for ConfigurationOfGlamour. Updating Monticello leads to the same result. Did I misunderstood something about how monticello works? Any idea how to debug this? Cheers, Andrei [1] (ConfigurationOfMoose project version: #'stable') record loadDirective

May 18, 2015

Re: [Pharo-dev] Trying to use Rubric in Nautilus ....

by Franck Warlouzet

Hi, With Alain's last commit of Rubric (205) we made a few changes to put Rubric in Nautilus. You can see thoses changes in the attached file. As you can see there is no colors in the browser... Is RubScrolledTextMorph>>beForSmalltalkCode the good option ? I thought there would be just an option like aboutToStyle: true or something like that but there is not. I do not know if I missed something obvious or if I have to add the connection to RubShoutStylerDecorator. Any idea everyone ? I am losing my eyes with uncolored code but I guess it is worth it. Thanks, Franck To: pharo-dev(a)lists.pharo.org From: pharo-dev(a)lists.pharo.org CC: alain.plantec(a)yahoo.com Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... Date: Thu, 14 May 2015 05:16:30 -0700 --PiÃ¨ce jointe du message transmise-- Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... From: alain.plantec(a)yahoo.com Date: Thu, 14 May 2015 14:16:16 +0200 To: pharo-dev(a)lists.pharo.org done & committedCheersAlain On 14 May 2015, at 12:06, Alain Plantec <alain.plantec(a)yahoo.com> wrote:ahh, good remark :)the menu stuff is not finished.I do it nowthanks Alain On 13 May 2015, at 18:09, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote:Hi alain thanks a lot! This helps us a lot. We got nearly something working. We will produce a list of methods and changes we had to do. see in the attached cs. Now lookupMenu "default implementation of the algorithm that lookup the menu" | default | default := [ self editingMode menu ]. ^ self model ifNil: [ default value ] ifNotNil: [ :m | m menu ifNil: [ default value ] ] We add a new method in nautilus that creates a menu as follow because m is our NautilusModel menu ^ self sourceCodeMenu: MenuMorph new shifted: false. But I was wondering why m menu does not take into account the information we passed when we created the rubPluggable sourceTextArea := self textMorphClass on: self text: #sourceCodeFrom: accept: #compileSource:notifying: readSelection: #contentsSelectionFrom: menu: #sourceCodeMenu:shifted:. I see that RubEditingArea has a policy but we could find how we can improve RubPluggable to use the menu: To: pharo-dev(a)lists.pharo.org From: pharo-dev(a)lists.pharo.org CC: alain.plantec(a)yahoo.com Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... Date: Wed, 13 May 2015 07:26:15 -0700 --PiÃ¨ce jointe du message transmise-- Subject: Re: [Pharo-dev] Trying to use Rubric in Nautilus .... From: alain.plantec(a)yahoo.com Date: Wed, 13 May 2015 16:25:34 +0200 To: pharo-dev(a)lists.pharo.org see Rubric-AlainPlantec.196 in the Rubric repo. Iâve added RubPluggableTextMorph and RubPluggableTextMorphExample.Need to be polished certainly but it should facilitate the integration of Rubric in Nautilus. cheersAlain On 12 May 2015, at 22:45, stepharo <stepharo(a)free.fr> wrote:For fun I put the following trace in sourceCodeFrom: aTextMorph Transcript show: '.'. ^ self sourceCodeAnd in general this method is invoked three times instead of one :) Before asking we read all the examples and I saw that selector: is used to communicate and update the code pane. (UIManager default newAutoAcceptTextEntryFor: self get: #selector set: #selector: class: String getEnabled: #haveClassName help: 'Enter a selector' translated entryCompletion: entryCompletion) acceptOnCR: false; ghostText: 'Selector'; withDropListButton; I think this is only for the drop down list. What I meant is that I could use set: and pass the selector to be invoked by the dropdown when the drop down is selected. And it will notify self with the selector: selector. So we could sepcify any selector (ie I can register to the drop box and say call me once you are set). In RubMethodEditingExample>>#selector: it calls the update explicit self updateCodeWith: (cls sourceCodeAt: selector) and updateCodeWith: sets the text on the text model. Now my problem (and may be there is not solution) is how can I connect from a pluggableListMorph to a RubScrollText when the list does not generate announcement. This is why I tried to pass via dependents or something like that. I will try to generate announcements but this is a lot more work and I do not know if it will work. Stef <glueRubNautilus.2.cs>

May 18, 2015

Re: [Pharo-dev] Project set up

by Stephan Eggermont

On 17-05-15 16:55, valmy roi wrote: > Is there a way to export a project from pharo? I explain: create a set > up of a project (game for example) so that i can give it to someone > to play, and he will not need to import it in pharo. > If it doesn't exist, it should de created We do not yet have a fully automated way of doing that. Often, giving someone a zip with a vm and image folder is enough. If you are selling a software product you might want to provide a complete installer and a very much trimmed image. Each project is different in what it can unload. Do you want to be able to update the image online? DrGeo is one, you can also take a look at how the PharoLauncher is build and deployed. That provides another way of doing it. There are many options, so a script provides a reasonable way of doing this. Stephan

May 18, 2015

Re: [Pharo-dev] Please integrate 15523 and 15468

by Sean P. DeNigris

stepharo wrote > Sean I did not integrate it because it changes the package of the halt > methods. > I think that it would be good to have a package with all the Halt and > methods, because we do not need to have them all in kernel. I'd be happy to make that change, but I'd like to do it as a separate issue since a) the dependency already existed before this fix, and b) I have a few questions about exactly how to do that, which I don't want to hold up this change I made another issue for the dependency: Issue 15536 Halt: Extract from Kernel https://pharo.fogbugz.com/default.asp?15536 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Please-integrate-15523-and-15468-tp4826949p4827063.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 18, 2015

Re: [Pharo-dev] [ANN] Garage 0.2 - GarageGlorp - GarageConnectionPool

by Guillermo Polito

El lun., 18 de may. de 2015 a la(s) 1:08 p. m., phil(a)highoctane.be < phil(a)highoctane.be> escribiÃ³: > Ah, one thing with idle connections, it would be nice to have a keepalive > statement (like issued every x seconds to keep the connection alive). > noted ^^ > > Phil > â >

May 18, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Garage 0.2 - GarageGlorp - GarageConnectionPool

by Sven Van Caekenberghe

Great work, thanks a lot ! > On 18 May 2015, at 12:27, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > little announcement here. > > Updated Glorp v1.11 > ================ > I updated/merged latest configurations of Glorp with latest changes fixing TimeStamps and similar. I have fully green test cases in Pharo 5. > Latest version of the configuration is in Glorp's repository and copied to the corresponding MetaRepos. > > GarageGlorp v0.1 > ============= > A Garage extension to connect it to Glorp. All Glorp tests are green in Pharo3 and Pharo4. > > https://ci.inria.fr/dbxtalk/view/Garage-Glorp/ > http://guillep.github.io/DBXTalk/glorp.html > > Garage 0.2 > ======== > Some patches on Garage 0.1 were required to make garage glorp work. > - rows should be more polymorphic with arrays > - added isResultSet telling if the result of a query has rows > > Garage Connection Pool v0.1 > ====================== > A connection pool package featuring > - control of idle connections > - control of maximum connections to create > > http://guillep.github.io/DBXTalk/garage/connection_pooling.html > > Cheers, > Guille

May 18, 2015