Hi!
I have found and fixed a bug in the Sugiyama layout. Example of usage:
b := RTMondrian new.
b shape box color: Color red.
b nodes: (1 to: 100).
b edges connectFrom: [ :v | v // 2 ].
b layout sugiyama.
b normalizer
normalizeSize: #yourself;
alphaColor: 0.4.
b
Here is a screenshot in Hapao:
:-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
With the latest GT integration, we also integrated the search for senders and references from the first step.
Here is a detailed explanation about it, including what we still want to do, how it’s done, and how to discover what else is around:
http://www.humane-assessment.com/blog/spotting-senders-references-with-gtsp…
Please let us know what you think.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Hi,
A new version of GTDebugger was just integrated. Several issues were addressed. Some more notable things are:
- the stack shows columns for class, method, other info
- there are new keybindings in place that do not collide with the text editor
- the accept/cancel buttons are in the contextual menu at least for Pharo 5
- the variables pane received a label
There are still some things todos left like:
- the columns in the stack should be resizable
- thisContext, stackTop
- perhaps make the key bindings controllable through settings
We kindly invite everyone to test it and provide feedback.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Quality cannot be an afterthought."
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>:
> 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.
>
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the contents
didn't changed - tested on
Latest update: #50524 )
Most (all?) other tools don't have Accept/Cancel buttons.
- I really miss the "List Methods using 'varname'/List Methods storing into
'varname'
- is "stackTop" now gone ? I thought you wanted to add it to the stack ?
- thisContext is gone as well ?
- the Bytecode/GT button is badly placed, it looks like the "downarrow"
window menu icon
is a dropdown menu with label "Bytecode" (since when do we put buttons in
the title pane?
- the evaluator pane is shown as "dirty", as it does not make a difference
if we
accept the text in this pane, there shouldn't be a dirty indicator.
- you can not use the inspector pane to change inst var values
- there is no way to refresh the inspector pane
I don't open bugtracker entries now, I 'll wait maybe this issues aren't
bugs but
features.
nicolai
Hi,
So, the VM was updated and the become: issues are solved. There is now only 1 failing test:
https://ci.inria.fr/moose/job/moose-6.0/1077/testReport/junit/Moose.Tests.F…
The problem is that MooseOutgoingCompositeQueryResult doesNotUnderstand #atScope:
I suspect it has to do with the new addition of the Moose Query implementation. Could someone look at the new Moose Query?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Obvious things are difficult to teach."
Hi,
Does anyone knows why when using PetitParser Browser, the debugger tab presents a tree composed of only one or maximum two elements (even if it enters more rules)?
Any help will be useful because debugging petitParser code is really hard.
Thanks.
Anne
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the contents
didn't changed - tested on
Latest update: #50524 )
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>:
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
> www.feenk.com
>
> "Beauty is where we see it."
>
>
>
>
>
Dear all,
As I mentioned in the thread "Pharo Consortium Sponsored Development
Effort" [1] I built a survey about Forking Operating System Processes in
Pharo.
The idea of the survey is simple: I want to understand what people needs
the most, which features would be useful, which ones would not, what is
missing, what is wrong, etc etc etc. As always, since we have limited
resources, we should optimize them as much as possible.
I count with you so that we can make a roadmap together on this project.
Please, feel free to forward this survey anywhere where there could be an
interest.
https://www.surveymonkey.com/r/DHR22TL
Best regards,
[1]
http://forum.world.st/ANN-Pharo-Consortium-Sponsored-Development-Effort-td4…
--
Mariano
http://marianopeck.wordpress.com
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.comwww.feenk.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
