happy and bold new year
by Tudor Girba
Happy New Year, everyone!
Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year.
Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk:
https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA
I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that.
In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk:
https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA
It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are.
I wish you a happy and bold new year!
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"Every thing should have the right to be different."
5 years, 7 months
Design Challenge: metrics missing value...
by stepharong
Hi dear great OO designers
Here is a little challenges for your brainy souls :)
In Moose when we compute metrics it may happen than a tool (often external
to pharo) does not compute a metrics
and when we request it in moose we check and often we return a not so good
-1.
I'm trying to brainstorm on a solution
- first may be the simplest way is to not invoke a metrics when it is not
computed. But it means that we should know it and that we should have a
registration mechanism. After all this is probably the best solution.
- Second we were thinking to use exception but when we have multiple
entities missing one metrics.... I have serious doubts.
- Second I was thinking about having the following behavior
testCollect
| uarray collected |
uarray := UniformOrderedCollection new.
uarray add: 10.
uarray add: 20.
uarray add: (MissingValue discarding).
collected := uarray collect: [ :each | each ].
self assert: collected size equals: 2.
testDo
| res uarray |
uarray := UniformOrderedCollection new.
uarray add: 10.
uarray add: 20.
uarray add: (MissingValue discarding).
uarray add: 40.
res := 0.
uarray do: [ :each | res := res + each ].
self assert: res equals: 70.
testCollectDefaulting
| uarray collected |
uarray := UniformOrderedCollection new.
uarray add: 10.
uarray add: 20.
uarray add: (MissingValue default: 33).
collected := uarray collect: [ :each | each ].
self assert: collected size equals: 3.
self assert: collected third equals: 33
I basically started to implement
do: aBlock
"Refer to the comment in Collection|do:."
1 to: self size do:
[:index | (self at: index) toDo: aBlock on: self]
collect: aBlock
"Evaluate aBlock with each of the receiver's elements as the argument.
Collect the resulting values into a collection like the receiver. Answer
the new collection."
| newCollection |
newCollection := self species new.
self
do: [ :each | each toCollect: aBlock on: newCollection ].
^ newCollection
and
DiscardingValue >> toCollect: aBlock on: aCollection
"discard computation"
^ self
Object >> toCollect: aBlock on: aCollection
^ aCollection add: (aBlock value: self)
So I imagine that you see the design and I wanted to get your point of
view.
--
Using Opera a kind of bad mail client but far better than thunderbird
5 years, 7 months
Re: [Pharo-dev] happy and bold new year
by Tudor Girba
Hi,
In my opinion, Pharo provides the strongest infrastructure for understanding a system from all technologies I have seen. So, if you say that Pharo is a bit "under featured in, then I think we are not referring to the same thing :).
May I ask how you are using the inspector? For example:
- do you extend the inspector?
- do you construct visualizations about your system in the inspector?
- do you write queries about code in the inspector?
Cheers,
Doru
> On Jan 9, 2017, at 3:42 PM, Hilaire <hilaire(a)drgeo.eu> wrote:
>
> I know this path of understanding code while it is running (inspector or
> debugger), but it is still a tedious path, and I feel Pharo is a bit
> under featured on that specific department, therefore my question on Moose.
>
> Hilaire
>
>
>
> Le 09/01/2017 à 15:09, Tudor Girba a écrit :
>> That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far.
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
--
www.tudorgirba.com
www.feenk.com
"We can create beautiful models in a vacuum.
But, to get them effective we have to deal with the inconvenience of reality."
5 years, 7 months
Re: [Pharo-dev] happy and bold new year
by Tudor Girba
Hi Hilaire,
GT is essentially a project that takes the relevant parts of Moose and make them applicable to plain Pharo. Pharo ships with only the core tools, but the complete configuration of GT also brings with it Roassal and a couple of other goodies. There are still more interesting things in Moose, but you can get quite far with only GT.
About your particular question, it’s true that Pharo does not have static types, but that does not make it harder to understand. Only different. The first thing to realize is that Pharo is not about code, but about objects.
That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far.
I know this sounds abstract, but I am practicing this since several years and I still find it amazing. I tried to provide a hint of how it works in the ESUG 2016 talk.
Cheers,
Doru
> On Jan 9, 2017, at 2:02 PM, Hilaire <hilaire(a)drgeo.eu> wrote:
>
> Hello Doru,
>
> I am curious.
> Yesterday I had a look to MessageBrowser, and realize I understand
> nothing of it. I saw there is a mix of SpecXXX, models, Navigation
> browser, Announcement, etc, then I knew I will have to spend a lot of
> time browsing (multiple window again) to understand a bit how these
> objects are related, and may be be able to change it in the way I want.
> Does the Moose & al tools could help me understand code I don't know about?
>
> Given the fact Pharo/Smalltalk are not typed makes it harder for code
> analysis, don't you?
>
> Happy new year to you too.
>
> Hiaire
>
> Le 09/01/2017 à 10:30, Tudor Girba a écrit :
>> Happy New Year, everyone!
>>
>> Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year.
>>
>> Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk:
>> https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA
>>
>> I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that.
>>
>> In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk:
>> https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA
>>
>> It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are.
>>
>> I wish you a happy and bold new year!
>>
>> Cheers,
>> Doru
>>
>
> --
> Dr. Geo
> http://drgeo.eu
--
www.tudorgirba.com
www.feenk.com
"If you can't say why something is relevant,
it probably isn't."
5 years, 7 months
doing a pass on FAMIX-File
by Usman Bhatti
Hi,
I am using FAMIXFile and FAMIXFolder for a project. There are a few things
that I've improved.
FAMIXAbstractFile defines a variable for belongsTo, I renamed this variable
to parentFolder because AFAIK belongsTo is always derived information. I've
implemented parentFolder as a FMMutlivalueLink. The opposite is
childrenFileSystemEntities so that we've autoupdating back links.
This change has made make existing files and folders inst vars and their
accessors redundant. The selectors folder and files on a FAMIXFolder still
exist but they are computed from childrenFileSystemEntities. IMO, the
resulting solution is much more clean and more expressive.
Let me know if there's a conceptual regression or some cases not covered.
Usman
5 years, 7 months
Happy new year!
by Alexandre Bergel
Here is our traditional Roassal-flavored best wishes.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
points := Compiler evaluate: ' {(-225@ -206). (-225@ -196). (-228@ -185). (-228@ -174). (-230@ -164). (-218@ -182). (-209@ -182). (-197@ -182). (-190@ -207). (-192@ -194). (-190@ -187). (-192@ -170). (-190@ -161). (-180@ -161). (-176@ -171). (-167@ -185). (-162@ -197). (-151@ -208). (-143@ -202). (-140@ -193). (-124@ -164). (-136@ -183). (-133@ -175). (-159@ -181). (-150@ -181). (-142@ -181). (-97@ -165). (-101@ -181). (-101@ -193). (-103@ -206). (-104@ -210). (-88@ -211). (-77@ -210). (-80@ -199). (-89@ -193). (-61@ -171). (-63@ -182). (-64@ -213). (-67@ -200). (-64@ -191). (-54@ -207). (-38@ -210). (-54@ -190). (-40@ -188). (-35@ -195). (-35@ -200). (-42@ -207). (0@ -199). (0@ -194). (-6@ -179). (-4@ -185). (-10@ -171). (-11@ -163). (-17@ -201). (-13@ -194). (-9@ -190). (57@ -196). (58@ -190). (58@ -181). (58@ -176). (57@ -168). (62@ -193). (69@ -180). (68@ -183). (74@ -175). (80@ -163). (77@ -170). (80@ -172). (81@ -184). (81@ -197). (81@ -201). (95@ -198). (97@ -183). (97@ -162). (98@ -169). (97@ -172). (107@ -162). (116@ -162). (122@ -162). (103@ -178). (109@ -179). (101@ -198). (117@ -198). (111@ -198). (134@ -196). (151@ -179). (141@ -187). (154@ -170). (167@ -170). (176@ -200). (175@ -194). (160@ -195). (183@ -174). (171@ -181). (162@ -189). (187@ -181). (189@ -185). (197@ -198). (-147@ -105). (-156@ -98). (-156@ -89). (-163@ -82). (-165@ -94). (-180@ -111). (-174@ -103). (-167@ -74). (-134@ -102). (-137@ -89). (-135@ -79). (-136@ -73). (-126@ -67). (-119@ -68). (-122@ -86). (-128@ -84). (-128@ -102). (-119@ -102). (-99@ -72). (-86@ -102). (-92@ -96). (-96@ -88). (-77@ -99). (-62@ -75). (-73@ -88). (-63@ -75). (-54@ -67). (-91@ -81). (-86@ -79). (-77@ -79). (-29@ -61). (-33@ -109). (-33@ -96). (-32@ -88). (-32@ -82). (-32@ -75). (-31@ -71). (-22@ -101). (-14@ -101). (-9@ -89). (-15@ -86). (-25@ -86). (-19@ -80). (0@ -72). (-5@ -80). (-3@ -67). (-126@21). (-123@4). (-117@ -3). (-107@ -10). (-91@ -8). (-93@7). (-85@16). (-85@34). (-89@44). (-91@57). (-108@67). (-119@79). (-132@86). (-119@87). (-102@88). (-90@88). (-74@87). (-8@9). (-18@19). (-20@30). (-23@43). (-18@53). (-14@61). (-4@73). (6@78). (35@69). (38@55). (24@81). (15@82). (45@44). (37@35). (33@23). (24@14). (11@9). (2@7). (54@79). (66@69). (82@21). (74@56). (74@41). (78@39). (88@19). (88@28). (89@38). (90@79). (88@55). (89@49). (127@31). (131@21). (134@14). (152@10). (168@10). (177@13). (189@13). (192@14). (182@44). (188@35). (187@25). (171@56). (164@69). (152@82). (152@89). (141@93)}'.
delta := 30.
v := RTView new.
b := [ :pos |
e := (RTEllipse new
color: (RTPalette c3 atRandom alpha: 0.8);
size: 5 atRandom + 3) element.
d := ((delta atRandom - (delta / 2)) @ (delta atRandom - (delta / 2))).
e translateTo: pos + d.
v add: e.
v
addAnimation:
(RTAccelerationMove
to: pos
during: 10
on: e)
].
[points do: [ :p | b value: p. (Delay forSeconds: 0.1) wait ]] fork.
v open
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Here is the result of a nice animation:
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
5 years, 7 months
Using Moose outside of source assessment context?
by Udo Schneider
All,
I’m dabbling with the idea of using Moose in a totally different questions. However I do have some questions about using it in my context. Would this ML be the right place to ask those questions?
CU,
Udo
5 years, 7 months
jdt2famix - creating a binary release from sources
by Andre Hora
Hello Doru,
I am trying jdt2famix by creating a binary release from sources. After
creating the binary release, I run it on jfreechart (version:
54eeb32a0bbf61db346fa3d37ef94a00b9747b1c), and I have the following
exception.
obs: it works if I download and use "Release 1.0.3".
======== Script ===========
git clone https://github.com/girba/jdt2famix.git
cd jdt2famix
./release.sh
cd ..
git clone https://github.com/jfree/jfreechart.git
cd jfreechart/
git reset --hard 54eeb32a0bbf61db346fa3d37ef94a00b9747b1c
../jdt2famix/release/jdt2famix.sh
========= Exception ========
16:46:07 - importing file - 0163/1010 - /Users/andrehora/Desktop/
jfreechart/src/main/java/org/jfree/chart/fx/ChartCanvas.java
Exception in thread "main" java.lang.NullPointerException
at com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromVariableBindin
g(InJavaImporter.java:768)
at com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromExpression(
InJavaImporter.java:760)
at com.feenk.jdt2famix.injava.AstVisitor.visit(AstVisitor.java:454)
at org.eclipse.jdt.core.dom.Assignment.accept0(Assignment.java:309)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at org.eclipse.jdt.core.dom.ExpressionStatement.accept0(
ExpressionStatement.java:145)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.Block.accept0(Block.java:137)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(
MethodDeclaration.java:635)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(
TypeDeclaration.java:470)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.CompilationUnit.accept0(
CompilationUnit.java:212)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at com.feenk.jdt2famix.injava.AstRequestor.acceptAST(AstRequestor.java:30)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(
CompilationUnitResolver.java:1029)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(
CompilationUnitResolver.java:636)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:990)
at com.feenk.jdt2famix.Importer.run(Importer.java:39)
at com.feenk.jdt2famix.injava.Main.main(Main.java:30)
--
Andre Hora
5 years, 7 months
jdt2famix - creating a binary release from sources
by Andre Hora
Hello Doru,
I am trying jdt2famix by creating a binary release from sources. After
creating the binary release, I run it on jfreechart (version:
54eeb32a0bbf61db346fa3d37ef94a00b9747b1c), and I have the following
exception.
obs: it works if I download and use "Release 1.0.3".
======== Script ===========
git clone https://github.com/girba/jdt2famix.git
cd jdt2famix
./release.sh
cd ..
git clone https://github.com/jfree/jfreechart.git
cd jfreechart/
git reset --hard 54eeb32a0bbf61db346fa3d37ef94a00b9747b1c
../jdt2famix/release/jdt2famix.sh
========= Exception ========
16:46:07 - importing file - 0163/1010 -
/Users/andrehora/Desktop/jfreechart/src/main/java/org/jfree/chart/fx/ChartCanvas.java
Exception in thread "main" java.lang.NullPointerException
at
com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromVariableBinding(InJavaImporter.java:768)
at
com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromExpression(InJavaImporter.java:760)
at com.feenk.jdt2famix.injava.AstVisitor.visit(AstVisitor.java:454)
at org.eclipse.jdt.core.dom.Assignment.accept0(Assignment.java:309)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at
org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:145)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.Block.accept0(Block.java:137)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at
org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:635)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at
org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:470)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at
org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:212)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at com.feenk.jdt2famix.injava.AstRequestor.acceptAST(AstRequestor.java:30)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1029)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:636)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:990)
at com.feenk.jdt2famix.Importer.run(Importer.java:39)
at com.feenk.jdt2famix.injava.Main.main(Main.java:30)
--
Andre Hora
5 years, 7 months
