May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

With Peter we cleaned some subscription for enabled that were register twice. https://pharo.fogbugz.com/f/cases/18175/Cleaned-up-code-duplication-in-init… Stef and Peter Le 4/5/16 Ã 18:16, stepharo a Ã©crit : > First we should clean it, then we speed it up. > > > Stef > > > Le 4/5/16 Ã 15:45, Stephan Eggermont a Ã©crit : >> On 04/05/16 13:43, Peter UhnÃ¡k wrote: >>>> >>>> by a factor of at least 2,5x compared to pure Morphic (I've seen a >>>> 5x). >>>> >>> >>> This doesn't mean anything. Can you please provide concrete numbers >>> (what >>> you experience) and what is your expected target? Because I do not have >>> such problematic experience. >> >> Thierry develops on a machine that is somewhat slower than those most >> Pharo users develop on: a Celeron 2955U machine. For Pharo I'd hope >> to be able to reasonably do development on a Raspberry Pi2. >> >> He is very aware of Morphic performance issues, so that factor 2.5 is >> not the layout processing, as that is the same for Morphic and Spec. >> >> We could add some Spec performance tests to jenkins/travis to see >> when we have regressions. >> >> Stephan >> >> >> > > >

May 8, 2016

Help on using Git with Pharo

by Alexandre Bergel

Hi! I have written a help to use Git in Pharo. Execute the following: Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load. It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help One some point, I will propose an inclusion in the base image. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Peter UhnÃ¡k

Hi, today with Stef we spent some time going through Spec. But first to address some points In AbstractWidgetModel we have > dragEnabled dropEnabled dragTransformationBlock wantDropBlock > acceptDropBlock transferBlock > That needs to be one instance variable dealing with drag and drop. We question whether this belongs to AbstractWidgetModel, as only three (TreeModel, ListModel, and TabModel (iirc)) benefit from it in any way. One option would be to have an intermediate subclass so we can move at least some of it, like this â As for separating into a separate instance variableâ¦ I agree from design perspectiveâ¦ however having directly available methods is very user-friendly when you are configuring it, because you can use a cascade. ^ TreeModel new roots: #(a b c d); childrenBlock: [:it | it = #c ifTrue: [ {1. 2. 3} ] ifFalse: [ {} ]]; dragEnabled: true; dropEnabled: true. Which is quite nice. Without it you would have to do (tm := TreeModel new) roots :#(..); childrenBlock: [ :it | ... ]. tm dragAndDrop dragEnabled: true. tm dragAndDrop dropEnabled: true. There are different ways how to have it separate and provide and nice-ish API, for example keep the messages, but delegate the behavior. Or provide a configuration block. This is for example used when you are configuring a MenuModel/MenuGroup/MenuItem. ^ TreeModel new roots: #(...); childrenBlock: [ :it | ... ]; dragAndDrop: [ :dnd | dnd dragEnabled: true; dropEnabled: true ] The same questions also applies to Styles (color, borderColor, borderWidth). Which I would prefer to remove altogether (it's not really used, and I question whether whether it even belongs to Spec side). If we want to keep it, then separating it would be a nice idea (I've started, slice in Pharo60Inbox) ComposableModel: aboutText seems to be in the wrong place. > That is a WindowModel property, and we seem to need some kind of > mechanism to propagate property access in the widget hierarchy. I though so too at first, however this is very same as #title. In fact having directly in ComposableModel is very convenient. MyFormEditor>>title ^ 'Form Editor' MyFormEditor>>aboutText ^ 'Neither #aboutText, nor #title is actually used by MyFormEditor, but by WindowModel, but it makes for nicer API' ComposableModel: keyStrokesForNextFocusHolder keyStrokesForPreviousFocusHolder > I'm pretty sure I do not want focus switch to be an individual widget concern Take a look at http://smalltalkhub.com/#!/~StephaneDucasse/Deprecator We started cleaning up the API a bit. The idea is to start from Spec side, figure out what we need and then adapt adaptorâ¦ and not try to reimplement Morphic. Right now only ButtonModel (ButtonPresenter) is done, but without shortcuts. We would like to introduce some common/uniform behavior for this instead of each Widget redoing it in a chaos. And some more cleanup sits in Pharo60Inbox... Peter On Thu, May 5, 2016 at 1:18 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 04/05/2016 19:18, Stephan Eggermont a Ã©crit : > >> >> >> On 04/05/16 18:18, stepharo wrote: >> >>> Can you open bug entries with such points? >>> >> >> 18164 Put drag-and-drop behaviour in one object >> >> 18165 ComposableModel: aboutText seems to be in the wrong place >> >> 18166 Where should focus change keystrokes be handled? >> > > For this one there was an debate about the following point: why Spec needs > to reimplement the focus change keystroke implemented by Morphic? > > Thierry > > Stephan >> >> >> >> > >

May 7, 2016

Re: [Pharo-dev] Big clap to OSSubprocess

by Mariano Martinez Peck

Thanks Alex! I did not answer your question the other day not because I did not read it but because I saw you figure it out yourself :) On Sat, May 7, 2016 at 3:53 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Easy to use, well commentedâ¦ > > Thanks Mariano! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Mariano http://marianopeck.wordpress.com

May 7, 2016

Big clap to OSSubprocess

by Alexandre Bergel

Easy to use, well commentedâ¦ Thanks Mariano! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 7, 2016

Re: [Pharo-dev] UFFIOpenGL binding and Woden is now working in Pharo 5

by Tudor Girba

Hi Ronie, Would it be possible to provide Ricky with some pointers so that he can port his CodeCity to your new binding? Cheers, Doru > On Apr 30, 2016, at 11:09 AM, Richard Wettel <wettel(a)gmail.com> wrote: > > Hi Ronie > > Thank you, that is great news! > I was talking to Doru the other day about investing some time in the OpenGL binding and you did it in the meantime. > > You are saying that it is not working like the previous binding, in that it does not provide support for creating an OpenGL context or a morphic. As far as I can tell CodeCity rendering is based on exactly that, so I was wondering if you could provide some tips on what would be needed to make CodeCity work with the new binding. > > Cheers > Ricky > > > _____________________________ > From: Ronie Salgado <roniesalg(a)gmail.com> > Sent: Friday, April 29, 2016 15:37 > Subject: [Pharo-dev] UFFIOpenGL binding and Woden is now working in Pharo 5 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, > > I made new OpenGL bindings for Pharo 5 using the UFFI (Available at: http://smalltalkhub.com/#!/~ronsaldo/UFFIOpenGL ). > > Unlike the old NBOpenGL, these new bindings make a heavy use of OSWindow SDL2 which is integrated and enabled by default in the Pharo 5 image. These bindings do not provide a way to create an OpenGL context or to create a Morphic window using OpenGL unlike NBOpenGL. > > For testing quickly OpenGL in Pharo 5, it should be enough to do the following in the playground: > > (ConfigurationOfOSWindow project version: #stable) load: 'WithOpenGLAndExamples'. > > (Smalltalk at: #OSGLExampleBasic3) new. > > As for Woden, it is now working in Pharo 5 with the UFFI. For loading Woden in a Pharo 5 image, is enough to do the following in the playground (Also available at the Woden Smalltalkhub page): > > Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load.(Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge. > > For an example the following script should be executed in a Playground: > > WDFPSSimpleExample6 new open. > > Greetings, > Ronie > > > -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

May 7, 2016

Re: [Pharo-dev] [Moose-dev] Re: extending GTDebugger

by Peter UhnÃ¡k

Hi Andrei, well I don't know exactly what I want... my initial idea was to quickly stick something together and see what is available to me and what I can do. But the overall idea is to extend the debugger to see metalinks-related infoâ¦ such as the currently installed metalinks in a method, which one was called, stepping into and over the metalinks, etc. But I'll start small with some windows and slowly see where I can go from there. Alsoâ¦ does the debugger uses regular Glamour? Can I read the Glamour docs to help me understand it? (I remember reading about Glamour long time ago and it had things like transmissions and portsâ¦ so maybe I can learn the behavior there.) Thanks, Peter On Fri, May 6, 2016 at 4:23 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Peter, > > Yes, extending the debugger is more work than extending the inspector. > However it depends on what you want to do. Do you need to change the UI of > the debugger or just add new actions? > > To create a new UI you need to subclass GTSUnitDebugger and > override debuggerStructureIn: and debuggerTransmissionsIn:. You can the > extend the UI using glamour presentations. On the class side of your UI you > need to implement #defaultTitle, #handlesContext:. If you need to customize > it more you can override at #helpClass, #sessionClass, > #variablesBrowserClass and #availableAutomatically. > > To create new actions you need to create subclasses of DebugAction. There > are a lot of examples in the image. To link a action with a UI widget you > need to add to the class side a method that just has an annotation. > Different widgets load actions that have various annotations. For example > the stack widget loads actions annotated with #gtStackDebuggingAction. > > Let me know if you need more information to get started. Unfortunately > there isn't a guide that you can use. > > Cheers, > Andrei > > > > On Fri, May 6, 2016 at 2:54 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> is there some guide / help how to extend the GTDebugger? >> >> I tried to take a look at SUnit/PParser but it looks quite complexâ¦ >> certainly more complex than extending Inspector. :) >> >> Thanks, >> Peter >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

May 7, 2016

Jenkins CI error

by Esteban A. Maringolo

Who is in charge of the Jenkins installation for http://ci.inria.fr/dbxtalk. I'm trying to modify certain projects and I'm getting the following error: Error JSONObject["scm"] is not a JSONObject. I tried some hacks to make it work, but no luck. Did this happen to somebody else? How to fix it? Regards! Esteban A. Maringolo

May 6, 2016

Re: [Pharo-dev] BlueInk shouldn't add parentheses when not needed

by Alistair Grant

On 6 May 2016 at 10:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have seen this too, and I hate it as well. > > I would definitively prefer the minimal syntax: no parenthesis when not needed, not extra $# when not needed. > >> On 06 May 2016, at 10:26, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> And second, perhaps less important... do we really need to reformat #(name owner uuid) into #(#name #owner #uuid)? Seems a bit superfluous too. I'll put in a vote the other way. As a new-to-Pharo user it is much faster for me to understand what is happening with the #'s present. Cheers, Alistair

May 6, 2016

Re: [Pharo-dev] [Moose-dev] extending GTDebugger

by Andrei Chis

Hi Peter, Yes, extending the debugger is more work than extending the inspector. However it depends on what you want to do. Do you need to change the UI of the debugger or just add new actions? To create a new UI you need to subclass GTSUnitDebugger and override debuggerStructureIn: and debuggerTransmissionsIn:. You can the extend the UI using glamour presentations. On the class side of your UI you need to implement #defaultTitle, #handlesContext:. If you need to customize it more you can override at #helpClass, #sessionClass, #variablesBrowserClass and #availableAutomatically. To create new actions you need to create subclasses of DebugAction. There are a lot of examples in the image. To link a action with a UI widget you need to add to the class side a method that just has an annotation. Different widgets load actions that have various annotations. For example the stack widget loads actions annotated with #gtStackDebuggingAction. Let me know if you need more information to get started. Unfortunately there isn't a guide that you can use. Cheers, Andrei On Fri, May 6, 2016 at 2:54 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is there some guide / help how to extend the GTDebugger? > > I tried to take a look at SUnit/PParser but it looks quite complexâ¦ > certainly more complex than extending Inspector. :) > > Thanks, > Peter > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

May 6, 2016