Hi,
We are happy to announce that the moldable editor helped us create a richer transcript: GT Transcript.
The transcript is traditionally a stream of plain text. As we now have an elaborate editor, we can take advantage of it to help us display richer representations.
The API is backward compatible with the existing transcript. To enable the new features, we introduced a builder. For example:
transcript nextPutAll: ‘something’
becomes
transcript next putAll: ‘something’
and after #next we can add multiple attributes that we want to affect the following insertion of a text.
Below you can find an example detailing most of the API. The most notable additions is the support for expandable adornments. For example, #showException: provides an in-place expansion of the stack of the exception context.
To get an idea of how this tool can be useful, take a look at the following video showing the visual logging of a Bloc animation:
https://youtu.be/9VATYNaLwJY
The code can be found in the new incarnation of GToolkit:
Iceberg enableMetacelloIntegration: true.
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
“Software has no shape. Actually, it has no one shape. It has many."
Hi,
When we announced the GT Documenter as an application for the moldable editor, one of the remarks was that GT Examples implementation relies too much on pragma magic.
We are now happy to announce that this is no longer the case because Andrei did a great job and rebuilt examples without the need for static pragmas for specifying dependencies.
So, now we can example dependencies simply through normal calls:
emptyView
<gtExample>
^ GtMondrian new
twoNodes
<gtExamples>
view := self emptyView
view nodes with: {1 . 2}
... and the engine can figure out the static dependencies. This means that examples can be used both as plain unary methods, and as replacement for tests. We think this should address the worry of examples being too heavy (the current implementation is ~350 lines).
With a bit of extra effort, we also adapted GT Documenter to expand the example dependencies as seen below. This means that examples can now be used directly as units of documentation as well.
We think this is significant.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"We are all great at making mistakes."
Hi,
We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions.
To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc.
Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example.
Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet).
Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, let’s leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors).
A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. It’s really cool.
Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable.
We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it.
All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0:
Iceberg enableMetacelloIntegration: true.
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.
And then inspect:
'./pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"Innovation comes in the least expected form.
That is, if it is expected, it already happened."
That is ok :) Those are not used modules and can be ignored.
I am glad it worked! I will see, maybe it is possible to get rid of at
least one gtk dependency.
Cheers,
Alex
On Aug 18, 2017 6:19 PM, "stephan" <stephan(a)stack.nl> wrote:
On 18-08-17 17:12, Aliaksei Syrel wrote:
> echo "Installing GTK-2.0...";
> sudo apt-get install libgtk2.0-0:i386;
> echo "Installing GTK-3.0...";
> sudo apt-get install libgtk-3-0:i386;
>
Great, that works. Those two were missing.
Stephan
It still complains:
Installing library to File @ /home/stephan/Desktop/pharo6.1
/bin/lib/pharo/5.0-201707201942/libMoz2D.so
Launching Moz2D services...
Gtk-Message: Failed to load module "overlay-scrollbar"
Gtk-Message: Failed to load module "gail"
Gtk-Message: Failed to load module "atk-bridge"
Gtk-Message: Failed to load module "unity-gtk-module"
(pharo:8447): Gtk-WARNING **: Unable to locate theme engine in module_path:
"murrine",
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Hello
Who can help to get a Pharo 6.0/6.1 catalog entry for PetitParser and YAML?
Who is maintaining PetitParser?
I successfully did a manual installation
Repository:
MCSmalltalkhubRepository
owner: 'Moose'
project: 'PetitParser'
user: ''
password: ''
I loaded
Name: ConfigurationOfPetitParser-TudorGirba.80
Author: TudorGirba
Time: 13 September 2016, 9:59:15.01645 pm
Then
ConfigurationOfPetitParser load
All 232 tests are green for PetitTests-Core and PetitTests-Tests
For YAML parsing I loaded
PetitYAML-PhilippeBack.11
Author: PhilippeBack
Time: 29 May 2017, 12:53:55.994195 pm
from the same repository.
All 76 tests are green.
How do these two packages get a Pharo 6.0/6.1 ** catalog entry?
Regards
Hannes
** The entry should be marked as '6.0'. The image has an 'about
information of Pharo 6.0-60510 and on the desktop it shows 6.0. But
the same image has been announced as version 6.1.
Hello Stephan,
> Yep. I tried with a clean 6.1 install.
> The Moz2D library is downloaded, but does not seem to be installed
> correctly
Below is the list of dependencies for *64bit Ubuntu* and *32bit Pharo*: (on
64bit pharo it should theoretically work out of the box, except 64bit
related issues)
> sudo dpkg --add-architecture i386;
> sudo apt-get update;
> export PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu/pkgconfig/;
>
> echo "Installing c++ libraries";
> sudo apt install libstdc++6:i386;
>
> echo "Installing GTK-2.0...";
> sudo apt-get install libgtk2.0-0:i386;
> echo "Installing GTK-3.0...";
> sudo apt-get install libgtk-3-0:i386;
>
> echo "Installing libGL...";
> sudo apt-get install libglu1-mesa:i386;
We have travis Build which is green:
https://github.com/syrel/Sparta/blob/master/.travis.ymlhttps://travis-ci.org/syrel/Sparta
On Windows users should install Visual C++ Redistributable for Visual
Studio 2015: (reduces binary size by >10mb)
https://www.microsoft.com/en-US/download/details.aspx?id=48145
On OSX works out of the box
Cheers,
Alex
On 18 August 2017 at 17:01, stephan <stephan(a)stack.nl> wrote:
> On 12-08-17 10:47, Tudor Girba wrote:
>
>> Is this still an issue?
>>
>
> Yep. I tried with a clean 6.1 install.
> The Moz2D library is downloaded, but does not seem to be installed
> correctly
>
> > Could you also try on another OS (just to make sure)?
>
> next step
>
> Stephan
>
>
Hi,
After another intense week, we are happy to announce that the Brick editor now supports some advanced syntax highlighting.
To put it in perspective, let us take a look at one screenshot showing an inspector presentation containing a Brick editor opened on a Pillar file that includes some text, a code snippet and a reference to a picture:
This shows both that we style the text based on the Pillar grammar, but also that we can style Smalltalk code (in fact, we have two nested stylers here).
But, the more interesting thing is that below the picture reference, we get to see the actual picture (which happens to be another inspector screenshot). In fact, this picture is actually just another text attribute (we call it an adornment) that can be dynamically added to any text elements. This opens up a whole lot of expression power and it is all easily compose-able. This is another reason why we say that this editor is moldable and you should expect new applications making use of this moldability and combining it with the liveliness of Pharo.
The latest Brick code is loadable through:
Metacello new
baseline: 'Brick';
repository: 'github://pharo-graphics/Brick/src';
load: #development.
If you want to play with Pillar, load the following extra code and just inspect a Pillar file:
Metacello new
smalltalkhubUser: 'Pier' project: 'Pillar';
configuration: 'Pillar';
version: #development;
load.
((IceRepository registry detect: [ :each | each name = 'Brick' ])
packageNamed: 'Brick-Editor-Pillar') loadLatest.
One other thing to mention is performance. What Alex (Syrel) managed to do is quite remarkable. To see the impact in practice, try editing the largest method in Pharo (UnicodeDefinitions class >> #data) in both the built-in editor and in the Brick editor by inspecting:
BrTextEditor onMethod: UnicodeDefinitions class >> #data
There are still issues left to deal with and we will focus on them in the following weeks. But, we can safely say that the most important challenges are now behind us and that the design of the editor code is stable and robust.
Please do let us know what you think.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
Is this still an issue?
Could you also try on another OS (just to make sure)?
Cheers,
Doru
> On Aug 10, 2017, at 2:12 PM, stephan <stephan(a)stack.nl> wrote:
>
> On 10-08-17 13:09, stephan wrote:
>> On 05-08-17 00:19, Tudor Girba wrote:
>> >Iceberg enableMetacelloIntegration: true.
>> That doesn't work. It hangs the image, keeping one CPU
>> busy.
>
> With 60510 that is non-interruptable, b.t.w.
>
> Stephan
>
>
>
>
--
www.tudorgirba.comwww.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Hi all,
I'm using MalGraphAlgorithm to build simulations of disease propagation on
random network and for performance reason, I need to store inside each
nodes of my network, the neigbours nodes.
I see a class MalNodeWithNext that store next edges, is it the class I
should use for my nodes ?
I see a trait called #MalTEdgeNode, is it related ? how it works ?
​Thank you.
Regards,​
--
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
