Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

happy lessons from recent talks
by Tudor Girba 11 Jan '16

11 Jan '16

Hi, I just wanted to share with you a bit of a different perspective on what we do around here. Over the past half a year I gave several talks to some 1k technical people at industrial events like ArchConf, NDC Oslo and several others. The tour will continue this year at OOP, ArchConf and a couple of other places. These are places where people talk about mainstream techniques & technologies (like Java, JS, C#). For example, ArchConf is a premier software architecture conference in the US. During these sessions, people get to experience Moose and Pharo through live demos. I use these demos as examples of how humane assessment (building your own analysis tools) can boost engineering decisions making in practice. I consistently receive the feedback that the live programming possibilities from Pharo/Moose are impressive. But, more recently, there is something else worthy of being noted. If in previous years, nobody heard about what we do, this year I started to get consistently a couple of persons in the room that have heard something about Pharo/Moose before the presentation. This is huge. While a couple might not sound like much, you should remember that information (especially in this technical space) has the capability of spreading exponentially. What we have done over the past years starts to show results. We have to keep it up. Happy New Year! Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

3 2

gtdebugger - icons with text and a couple of others
by Tudor Girba 11 Jan '16

11 Jan '16

Hi, Andrei and I took your feedback into account, and now we have this in the last version: - actions have text (this is a feature introduced in Glamour now) - the order of the code actions is better (accept is next to cancel) On top of that, there are a couple of extra features that we did not talk about until now: - whenever there is another kind of debugger available, a new button appears on the top right. When the Bytecode Debugger is loaded, you can always switch to it. Or, when you get in a situation in which the SUnit is available, you can switch to it. - the selection from the inspector is preserved when you move back and forth in the stack. - the panes in the inspector can be closed - stack highlighting is not on by default (it never was actually) - if you “Inspect and Go”, you inspect in place instead of the inspector at the bottom (no extra window) There are probably still glitches, but we think they are fixable. We still would like to add a couple of more features if there is time: - having a table in the stack to show class / method / package - having multiple inspectors in tabs when you inspect in place to not remove the original inspector Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

2 1

4 tests failing
by Tudor Girba 11 Jan '16

11 Jan '16

Hi, It looks like in the Spur image, the ghost instances of GTInspector are gone. So, now we have only 4 tests failing, and they all seem to be related to a possible problem with become:. I am not yet sure what the solution is, but I raised this issue on the Pharo mailing list. Cheers, Doru -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."

5 5

gtdebugger in pharo 5.0
by Tudor Girba 10 Jan '16

10 Jan '16

Hi, We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). For example, the core configuration includes also the SUnit and the bytecode debugger. These are around 150 lines of code. Here is how the bytecode debugger looks like: You can find more information in an introductory overview blog post that also includes some links for further reading: http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

6 14

Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0
by Torsten Bergmann 10 Jan '16

10 Jan '16

Hi, with a moldable debugger we should (in the future) be able to support debugging also different/other programming languages/DSLs in Pharo :) - although usually one does necessary have such a use case. So I guess GTInspector or other will be adopted to own needs more than GTDebugger. However: The only objection so far is that I dislike the order/size of the panes. The placement of the panes in GTDebugger (as for instance found in Moose) requires often to use the scrollbars of the pane showing the stack because of the text length. In GTDebugger the stack is at the top left, the source at the top right with a common splitter beneath the two panes: therefore the height (depth) of the stack pane is always the height of the code pane. When you have a long method to debug on the right much space is wasted for a deep stack on the left although you might only be interested in a few top frames. Contrary when you have are interested in a deep/full stack and you increase the height of the stack pane on the left you directly increase the height of the code pane and for short methods you waste a lot of space in the source pane as well. This is much better solved with the positioning in the traditinal Debugger: - Stack - Source - other So in my opinion We should preserve: - TOP: the stack at the top (using the full width of the window, so only vertical scrolling has to be done to "roll" on the stack, no need for horizontal scrolling as the area is wide enough) - MIDDLE: the source code pane in the middle (also using the full width of the window and there fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) - BOTTON: one or more panel for inspection at the bottom It would be OK for me if others like the new layout better - but at least there should be an option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Also the debugger window in Moose wastes a lot of space/has unused space within the windows client are itself. For instance the splitters are very thick which might be an issue of the moose theme. Thanks T. Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr Von: "Tudor Girba" <tudor(a)tudorgirba.com> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 Hi, We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). Here is an introductory overview blog post that also includes some links for further reading: http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ Please let us know what you think. Cheers, Doru -- www.tudorgirba.com[http://www.tudorgirba.com] www.feenk.com[http://www.feenk.com] "Beauty is where we see it."

3 5

Moose en Windows?
by Alexandre Bergel 08 Jan '16

08 Jan '16

Hi! Milton has trouble to run the last Moose (Spur based then) on Windows. Anyone is using Moose on Windows? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 7

Why there are 1000 tests less on Moose image between 7 oct and today?
by Blondeau Vincent 08 Jan '16

08 Jan '16

Hi, I am wondering why there are ~1000 tests less on Moose6.0 image between 7 oct and today. It seems that XML tests are not run anymore. Is it wanted ? Cheers, Vincent ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

4 5

inspecting an example?
by Alexandre Bergel 08 Jan '16

08 Jan '16

Hi! Consider the method: RTSunburstBuilderExamples >> basic15 <gtExample> | b mt | b := RTSunburstBuilder new. … ^ b By having the pragma I can run the example as a test. That is good, but I want to have the object inspected. Currently it does not. Is there a way to get the object inspected? With <script: ‘self new basic15 inspect’> instead of <gtExample>, then I could get it. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

Application UI embedded in the system browser?
by Alexandre Bergel 07 Jan '16

07 Jan '16

Hi! As you may know, in Pharo one can define an action using a #script pragma. This is useful for example to have examples as in: C class >> example01 <script> … This creates a small icon actionable next to the method name in the code browser. Clicking on it send the message #example01 to C. You can you have another pragma #script: as in: C>> example01 <script: ‘self new example01> … I have been using this kind of example because I want to have the examples available when I select a class. However, I see myself in using this pragma as a super easy way to have a button available in the code browser that execute something else than an example. For example, in one of my class, I have: -=-=-=-=-=-=-=-=-=-=-=-= SmallMultiple >> openMultiple <script: 'SmallMultiple new openMultiple inspect'> | b times c | times := OrderedCollection new. MCCVSImporter new blockToExecute: [ :line | … … SmallMultiple >> menuCommandOn: aBuilder <worldMenu> (aBuilder item: #'Small Multiple') label: 'Small Multiple'; icon: MatrixCubeIcons current cubeIcon; action: [ self new openMultiple inspect ] -=-=-=-=-=-=-=-=-=-=-=-= The method #openMultiple open a file browser and let the user to select a file and do some treatment on a .csv file. As you can see, this is not an example, but really the starting point of the application. All this long mail, to say that the code browser may not only be a place to look at code, execute tests, but also having user buttons to trigger and launch an application. By the way, there has been some effort with examples from the GT team. How does this compare with the #script: pragma? How to use it? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

copy artifact plugin
by Usman Bhatti 06 Jan '16

06 Jan '16

Copy artifact plugin in the jenkins wasn't correctly installed when we recovered from the glitches in Inria infrastructure. I've installed the plugin in the jenkins, however the jobs using the plugin prior to the problem do not have this step any more in their configuration. We'll have to add the step for red builds (i.e. copy required artefacts from the other upstream jobs). I've done it for a few but there are some jobs (GT-*) that I do not know what to copy and from where so we need to go through the failing builds.

7 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev