[Survey] Forking Operating System Proces in Pharo
by Mariano Martinez Peck
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-t...
--
Mariano
http://marianopeck.wordpress.com
7 years, 2 months
happy lessons from recent talks
by Tudor Girba
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."
7 years, 2 months
gtdebugger - icons with text and a couple of others
by Tudor Girba
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."
7 years, 2 months
4 tests failing
by Tudor Girba
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."
7 years, 2 months
gtdebugger in pharo 5.0
by Tudor Girba
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?"
7 years, 2 months
Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0
by Torsten Bergmann
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."
7 years, 2 months
Moose en Windows?
by Alexandre Bergel
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 years, 2 months
Why there are 1000 tests less on Moose image between 7 oct and today?
by Blondeau Vincent
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.
7 years, 2 months
inspecting an example?
by Alexandre Bergel
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 years, 2 months
Application UI embedded in the system browser?
by Alexandre Bergel
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 years, 2 months
