> Begin forwarded message:
>
> From: Sven Van Caekenberghe <sven(a)stfx.eu>
> Subject: [Pharo-users] [ ANN ] Pharo Days 2016
> Date: December 9, 2015 at 9:52:09 AM EST
> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org>
> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
>
> Dear fellow Pharoers,
>
> Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse.
>
> We’ll update the following page moving forward.
>
> https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf
>
> You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board.
>
> Let's make this another success, together ! We hope to see as many of you as possible.
>
>
--
www.tudorgirba.com
"We are all great at making mistakes."
Synectique is openning the source code for a C/C++ parser based on
Eclipse CDT.
https://github.com/Synectique/VerveineC-Cpp.git
The parser was developed as an Eclipse (Mars release) plugin and is
under MIT licence.
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
Hello,
Is there a way to set a default selection to a list presentation? so that
when I open the browser, the morphic list has already a value selected.
I tried that:
|tmpBrowser|
tmpBrowser := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
a list
display: [:input | input];
selection: #a;
yourself
].
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
Hello everyone!
Some month ago I sent a mail asking to ensure that all FAMIXEntities
could answer to all MooseQuery queries. The answer was no because the
community does not want some entities to be able to answer to every
query. (For example to have associations that can answer to navigation
queries).
This bothered me because we already have entities that can answer to
#children, #parents, #toScope:, #atScope:... even if it does not make
any sense.
Now I come back with a proposition to clean this half/half state and
to get a clean model query side.
I discussed these changes with Anne and she agrees with them.
In the current state of MooseQuery we have:
- TMetaLevelDependency used by FAMIXEntity that allow querying the
children, parents, and scopes of an entity
- TEntityMetaLevelDependency using TMetaLevelDependency. It adds the
navigation queries.
- TAssociationLevelDependency using TMetaLevelDependency. It adds some
useful methods to associations for the navigation queries.
We have two changes to propose.
First. It does not make any sense for TAssociationMetaLevelDependency
to use TMetaLevelDependency since an association should not be able to
answer to #children, #parents, #toScope:...
We propose to remove this usage. I did this change in an image and
launched MooseQuery/Chef tests, everything is green.
Second. TMetaLevelDependency does not make any sense when we have
TEntityMetaLevelDependency.
All the methods of TMetaLevelDependency are related to entities.
We propose to copy all the methods of TMetaLevelDependency to
TEntityMetaLevelDependency and remove it.
TMetaLevelDependency has two users: FAMIXEntity and
TEntityMetaLevelDependency. Since we copy the methods to the second
user, there is no problem with it. The biggest change is that now
FAMIXEntity will not implement any Meta trait. It does not need to use
any since all its subclasses should not understand generic queries.
The only change that needs to be done is to move the caches created on
FAMIXEntity to the users of TEntityMetaLevelDependencies.
I tried to apply this changes in a quick and dirty way to an image and
once again all tests seem to pass.
In conclusion, what do we win with this changes? All Famix entities
will only understand the queries they can answer to. FAMIXAssociation,
FAMIXSourceAnchor, FAMIXSourceLanguage will not understand anymore
#children, #parents, #toScope:, #atScope:...
Have a nice day :)
--
Cyril Ferlicot
https://ferlicot.fr
---------- Forwarded message ----------
From: Jigyasa Grover <grover.jigyasa1(a)gmail.com>
Date: Wed, Jan 10, 2018 at 6:10 AM
Subject: [Pharo-dev] Google Summer of Code 2018 with Pharo Consortium
To: pharo-dev(a)lists.pharo.org
Hello Pharo-ers !
On behalf of the community, I would like to thank each one of you for their
significant contribution in the previously concluded *Google Summer of Code
2017* with *Pharo Consortium*. We aspire to take-off on a long flight after
this successful stint by applying to participate in the upcoming *Google
Summer of Code 2018*.
As many of you might know, Google Summer of Code is a global program focused
on bringing more student developers into open source software development.
Students work with an open source organization on a 3 month programming
project during their break from school. Read more about the program here:
https://summerofcode.withgoogle.com/
The deadline for organisations to apply is January 23, 2018 which is fast
approaching. As an open source evangelist and a Pharo developer, I would
like to invite all the experienced members to be a part of the "GSoC 2018
with Pharo Consortium" Team and mentor students. Propose fresh ideas for
projects which shall help improve Pharo or volunteer to mentor any of the
existing one (Listed here: http://gsoc.pharo.org/). To add your own project
idea to the list, visit http://gsoc.pharo.org/#adding-a-proposal
Looking forward to an appreciable representation from the Pharo community.
Best regards
Jigyasa Grover
Pharo Consortium Org Admin, Google Summer of Code 2017 [hidden email]
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/
Hi,
Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.
It looks like this:
You can see it in action here:
https://twitter.com/feenkcom/status/936109463462965248
In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.
There are a couple of things that are worth noting:
• The editor works live, and the connection points appear and disappear as you type.
• The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).
• The editor works live, so adding new elements to the scene properly rearranges the scene.
• But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.
All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.
To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.
Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.
The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.
Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.
Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:
Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.
We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.…
Please let us know what you think.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"What is more important: To be happy, or to make happy?"
Hi,
I saw this test failure in Moose.
REPConcernTest>>testDefaults
self assert: REPConcern new label = #REPConcern.
This comes from
Name: Arki-Reporter-Core-TudorGirba.24
Author: TudorGirba
Time: 30 December 2017, 11:32:57.176429 pm
UUID: 2944c23a-f71d-0d00-88a2-a4180f45ebf9
Ancestors: Arki-Reporter-Core-GuillaumeLarcheveque.23
improve label
Since it seems intentional, I will update the test to this:
REPConcernTest>>testDefaults
self assert: REPConcern new label = 'REP Concern'.
self assert: REPConcern new explanation = 'REP Concern'.
--
Cyril Ferlicot
https://ferlicot.fr
Hi,
Happy New Year!
We were asked about the roadmap of Bloc several times. It is a perfectly reasonable request given that Bloc is supposed to offer the UI infrastructure for the future of Pharo.
However, I was reluctant to provide one because we do not really have a classic roadmap. When we develop Bloc and GT we think in terms of experiments and examples that we want to play with to get us to our goal. Features are a consequence of that. This approach allowed us on multiple occasions to stumble across functional possibilities that we would have not been able to think about before seeing the experiments. It also works the other way around: as we move ahead, we sometime discover modeling problems and we sometimes chase them all the way down.
Having said that, we can specify the next examples and experiments that we consider for the next months. Here they are:
• Drag and drop that can be customized on an instance basis. In the process, revisit event management and explore making it use Announcements. Use this for the diagramming engine.
• Scrollbar for infinite list and the scalable element.
• Apply layout once. For example, this would allow us to apply a layout but still be able to drag elements in custom positions without disturbing the others. The first application is in the context of creating diagrams and visualizations.
• Apply layout with animation. For example, in Connector, a new example should be spawned and moved to its position through a smooth animation. This will also allow us to play with the concept of animation and MVVM.
• Introduce the concept of elevation. This is important for scenes in which we have overlapping elements that are not part of the composition tree. For example, in Connector, the lines connect inner elements inside the text, but they belong to the root. such as a visualization (but not only). For this to work, we need a better element traversing structure.
• Experiment with theming. The theming mechanism should be instance specific with per-widget defaults, and the theme values should ideally be injected in the widgets. The CSS implementation from Glenn is one direction. As developing and maintaining themes can be a nightmare in the long run, the theming mechanism to provide debugging tools.
• Experiment with delegating animations through the model. Typical MVVM or MVC focus on the behavior of an interaction. We want to get smooth live interfaces and the animation logic should be influence-able by the model. For example, hovering over a button, enlarges the button with extra details about the action.
• Basic widgets: list, input box, button, radio button, checkbox, menu, dropdown menu, toggling button, tabs, toolbar.
• Table and tree widgets.
• Pager interface (similar to the one in the current inspector) with resizable panes.
Have fun,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"Presenting is storytelling."
