[Pharo-users] Re: [Pharo-dev] Pharo VM Release - v9.0.11

[Tudor Girba]

Awesome work!

Thank you,
Tudor

> On Jan 13, 2022, at 5:44 PM, teso...@gmail.com wrote:
> 
> Hello, 
>   I have released a new version of the Pharo VM for Pharo 9 and Pharo 10. 
> This VM is accessible right now from Zero-Conf, updating it in the Pharo 
> Launcher or using the usual downloads (as described in pharo.org/download). 
> 
> This version includes a series of minor bug fixes.
> 
> Changelog: 
> 
> - Include FloatArrayPlugin in the build
> - Updating SDL2 to 2.0.18 for OSX X86_64
> - Using Pharo 10 image as VMMaker image
> - Fixing issue in message counting on non-JIT VM
> 
> Thanks a lot, and any doubt please let me know.
> Cheers, 
> 
> Pablo on behalf of the whole Pharo team.
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com

--
feenk.com

"To lead is not to demand things, it is to make them happen."

[Pharo-users] Re: [Pharo-dev] [ANN] Pharo 9 released!

[Tudor Girba]

Congratulations!

Tudor

> On Jul 15, 2021, at 11:14 AM, Esteban Lorenzano  wrote:
> 
> Dear World and dynamic language lovers: 
> 
> The time has come for Pharo 9 !
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> Here are the key features of Pharo 9:   
> 
>   • Full redesign of the Spec UI framework (new logic, application, 
> style, GTK3 back-end)
>   • New tools:
>   •
>   • new playground,
>   • new object centric inspector,
>   • new object centric debugger.
>   • better and new Refactorings
>   • class comments are now written in Microdown format (Markdown 
> compatible)
>   • classes now can be defined using a "fluid" api (Preview)
>   • New completion framework that adapts better to edition contexts and 
> is customizable
>   • Fast universal non-blocking FFI which now uses libFFI as backend.
>   • Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora, 
> openSUSE, Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits).
>   • Virtual Machine
>   •
>   • Idle VM
>   • Support for ARM 64bits
>   • Support for Apple M1
>   • More than 3000 tests
>   • Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 
> 10, Testing; Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; Arch
>   • Uses SDL 2.0 as back-end by default. It supports extended event 
> handling, including trackpad support.
>   • General speed up due to compiler optimisations and UI simplification.
>   • And many, many more tests.
> 
> These are just the more prominent highlights, but the details are just as 
> important. We have closed a massive amount of issues: around 1400 issues and 
> 2150 pull requests.
> 
> A more extended changelog can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md.
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 9 image was contributed 
> by more than 90 people.
> 
> Pharo is more than code. It is an exciting project involving a great 
> community. 
> 
> We thank all the contributors to this release:
> 
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre Bergel, 
> Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano, Asbathou 
> Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos Lopez, 
> Carolina Hernandez, Charles A. Monteiro, Christoph Thiede, Christophe 
> Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel Aparicio, 
> David Bajger, David Sánchez i Gregori, Denis Kudriashov, Ellis Harris, Eric 
> Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban Lorenzano, Esteban 
> Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan Dawson, Francis 
> Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni 
> Corriga, Guille Polito, Himanshu jld, Johan Brichau, Jonathan van Alteren, 
> Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper Østerbye, Kurt Kilpela, 
> Laurine Dargaud, Marco Rimoldi, Marcus Denker, Martin Dias, Martin McClure, 
> Massimo Nocentini, Max Leske, Maximilian Ignacio Willembrinck Santander, 
> Milton Mamani Torres, Moussa Saker, Myroslava Romaniuk, Nicolas Anquetil, 
> Norbert Hartl, Nour Djihan, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, Pablo 
> Tesone, Pavel Krivanek, Philippe Lesueur, Pierre Misse, Rakshit P., Rob 
> Sayers, Roland Bernard, Ronie Salgado, Sean DeNigris, Sebastian Jordan 
> Montaño, Serge Stinckwich, Stephan Eggermont, Steven Costiou, Stéphane 
> Ducasse, Sven Van Caekenberghe, Thomas Dupriez, Théo Lanord, Théo Rogliano, 
> Todd Blanchard, Torsten Bergmann, Vincent Blondeau, Wéslleymberg Lisboa.
>  
> 
> (If you contributed with Pharo 9 development in any way and we missed your 
> name, please send us an email and we will add you).
> 
> Enjoy!
> 
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download
> 
> Learn Pharo: http://pharo.org/documentation

--
feenk.com

"No matter how many recipes we know, we still value a chef."

[Pharo-users] Re: [Pharo-dev] StackVM for M1 ready

[Tudor Girba]

Awesome news!

Thank you for all this work!

Doru

> On Feb 16, 2021, at 8:38 PM, Stéphane Ducasse  
> wrote:
> 
> Hello happy Pharoers
> 
> Today we could access our building where the M1 machine is and Pablo packaged 
> it
> so that you can test the first version. 
> 
> Pablo wrote a little blog post for you.
> 
>   https://thepharo.dev/2021/02/16/first-apple-m1-pharo-version/
> 
> Let us since we do not have the M1 at hand and waiting to be able to make it 
> accessible from 
> our build farm… but we are not responsible for it and we were waiting….
> But the crew was fixing other VM glitches. So we will be ready soon to focus 
> on the Jit version.
> 
> 
> S
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Aurore Dalle 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 

--
feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

[Pharo-users] Re: Can a class be not equal to itself?

[Tudor Girba]

Hi Konrad,

Could it be that you have overridden = on the class side of your class?

Otherwise, I do not see how this can happen.

Cheers,
Tudor



> On Dec 31, 2020, at 12:19 PM, Konrad Hinsen  
> wrote:
> 
> Hi everyone,
> 
> 
> It's been a while since I have encountered mysterious behavior in Pharo, but 
> today it happened. I set up a dictionary with classes as keys, and got "Key 
> not found" errors for keys that were definitely in my dictionary. A quick 
> debugging session showed the underlying issue: I had two references to a 
> class which look the same when inspected, but turn out to be not identical 
> (==) and thus not equal (=). How can this happen?
> 
> 
> Konrad.

--
feenk.com

"It's not how it is, it is how we see it."

[Pharo-users] Re: [Pharo-dev] [ANN] New Pharo VM released (v8.6.1)

[Tudor Girba]

Great work!

Thanks,
Tudor

> On Nov 2, 2020, at 4:48 PM, teso...@gmail.com wrote:
> 
> Hi,
> this is an announcement of a new release of the Pharo VM. This
> new version is available to be downloaded through get-pharo scripts
> and through the Pharo Launcher. From the Pharo Launcher, remember to
> update the VM from the VM manager window.
> 
> This version includes a series of improvements:
> 
> - Unification of code base with the headless VM
> - Preparation for supporting HDPI displays.
> - Improvements in the speed of Threaded FFI (40x times faster in
> SameThread runner and 2x in Threaded worker).
> - Better handling of semaphores
> - Improvements in the loading of large images (better buffering)
> - Better support for headless execution on non-main thread
> 
> Please let me know if you find any issues.
> 
> Cheers, Pablo
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com

--
feenk.com

“Software has no shape. Actually, it has no one shape. It has many."

Re: [Pharo-users] CV/OCR Library

[Tudor Girba]

Hi,

Indeed, we have an integration for OpenCV here:
https://github.com/feenkcom/gt4opencv

Cheers,
Doru



> On Aug 31, 2020, at 4:14 PM, Stéphane Ducasse  
> wrote:
> 
> I know that there is an openCV binding by https://twitter.com/DmitryMatveev 
> You have a binding in GT too. 
> 
> 
>> On 31 Aug 2020, at 14:40, Esteban Maringolo  wrote:
>> 
>> Hi,
>> 
>> Does anybody know if there is an OCR or some CV library available for Pharo?
>> 
>> I would like to make an experiment with recognizing the content of
>> some fixed size form, and of course I prefer to do it with Smalltalk
>> whenever possible.
>> 
>> Regards!
>> 
>> Esteban A. Maringolo
>> 
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Aurore Dalle 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 

--
feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-users] glamorous toolkit & pharo

[Tudor Girba]

Hi,

I am glad it was useful.

Our aim is to play the long term game and to sustain the evolution and support 
of GT. Time will tell if we succeed, but that is certainly the goal.

Cheers,
Doru



> On Jul 10, 2020, at 1:39 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> Is really good to see these advantages and the new features.
> 
> My main concern has been always a long term support and the...
> transportability of previous developments to future versions. There is
> any roadmap or Long Term Support or will Feenk act kind of like Pharo
> Pro for GT? Any place to find more information on this?
> 
> Cheers,
> 
> Offray
> 
> On 7/07/20 4:06 p. m., Tudor Girba wrote:
>> Hi,
>> 
>> As Glamorous Toolkit gets closer to being released, we get quite a number of 
>> questions on various channels about its relationship with Pharo.
>> 
>> Glamorous Toolkit is built with Pharo. It is unlikely that we would have 
>> been able to produce it in any other language within the constraints we 
>> faced.
>> 
>> At the same time, Glamorous Toolkit is a separate project produced by feenk 
>> with a distinct goal and its own realization.
>> 
>> Here is a short overview of what we mean by it:
>> https://blog.feenk.com/glamorous-toolkit-and-pharo-5aufgcequ38az2s0dj0t1nu0f/
>> 
>> Please do let us know if you have concerns or questions.
>> 
>> Cheers,
>> Doru
>> 
>> --
>> feenk.com
>> 
>> [fiːŋk]
>> verb
>> feel and think concomitantly.
>> 
>> 
>> 
>> 
> 
> 

--
feenk.com

"Quality cannot be an afterthought."

[Pharo-users] glamorous toolkit & pharo

[Tudor Girba]

Hi,

As Glamorous Toolkit gets closer to being released, we get quite a number of 
questions on various channels about its relationship with Pharo.

Glamorous Toolkit is built with Pharo. It is unlikely that we would have been 
able to produce it in any other language within the constraints we faced.

At the same time, Glamorous Toolkit is a separate project produced by feenk 
with a distinct goal and its own realization.

Here is a short overview of what we mean by it:
https://blog.feenk.com/glamorous-toolkit-and-pharo-5aufgcequ38az2s0dj0t1nu0f/

Please do let us know if you have concerns or questions.

Cheers,
Doru

--
feenk.com

[fiːŋk]
verb
feel and think concomitantly.

[Pharo-users] rdf and/or json-ld

[Tudor Girba]

Hi,

Is anyone aware of RDF or JSON-LD support in Pharo?

Cheers,
Doru


--
www.feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-users] Can't addChild:

[Tudor Girba]

Hi,

addChild: expects a BlElement not a canvas. A BlElement draws on a canvas 
object that is passed to it.

SpartaCanvas is an abstract class. If you want to instantiate a canvas, pick 
one of the subclasses.

For example, for MozCanvas, see MozExamples.

Cheers,
Tudor



> On Feb 25, 2019, at 4:55 PM, David Richards  
> wrote:
> 
> | canvas space node text |
> 
> . BlUniverse reset
> 
> . space := BlSpace new
> . space show
> . space title: 'Test Space'
> . space extent: 800@400
> . space root background: Color lightBlue 
> . space position: 1@25
>  
> . canvas := BlSpartaMozCanvasBuilder extent: 400@250
> 
> . space root addChild: canvas
> 
> This fails.
> 
> Any ideas how to create a Sparta Canvas, to draw some text on?
> 
> 

--
www.feenk.com

"There are no old things, there are only old ways of looking at them."

[Pharo-users] firebase client in pharo?

[Tudor Girba]

Hi,

Did anyone worked on connecting Pharo with Firebase?

Cheers,
Doru


--
www.feenk.com

"Quality cannot be an afterthought."

Re: [Pharo-users] Bloc Tutorial

[Tudor Girba]

Hi,

The simplest thing is to take a fresh image, in a fresh directory and rerun the 
Metacello script. Let us know how it works.

Cheers,
Doru


> On Feb 18, 2019, at 12:28 AM, horrido  wrote:
> 
> So how do I force Iceberg to reload?
> 
> 
> Andrei Chis wrote
>> If you use repositories that start with `github://` in Metacello you are
>> using Iceberg. Iceberg is used to clone and load the code. Metacello is
>> just the interface through which that is done.
>> 
>> Running the loading instruction does not pull new changes from remote
>> repositories.
>> 
>> On Sun, Feb 17, 2019 at 10:11 PM horrido 
> 
>> horrido.hobbies@
> 
>>  wrote:
>> 
>>> ???
>>> 
>>> I'm not using a cloned repository. I'm using Metacello just like in the
>>> snippet I showed you. Shouldn't it pull in the latest repo?
>>> 
>>> I've never used Iceberg; I don't know how to use it. I don't really want
>>> to
>>> fuck around with GitHub. I don't want to be pulled into a rabbit hole.
>>> 
>>> 
>>> 
>>> Andrei Chis wrote
 If you already have the repository cloned, running the code that you
 mentioned does not update the content of the repository.
 Hence, the existing version will be loaded again.
 
 Instead you need to do a pull using Iceberg to update the content of
>>> the
 repository and the code.
 
 Cheers,
 Andrei
 
 On Sun, Feb 17, 2019 at 8:06 PM horrido 
>>> 
 horrido.hobbies@
>>> 
  wrote:
 
> If you're referring to this:
> 
> Metacello new
>baseline: 'BlocTutorials';
>repository: 'github://pharo-graphics/Tutorials/src';
>load
> 
> It made no difference. Same error message.
> 
> 
> 
> Andrei Chis wrote
>> Hi,
>> 
>> Thanks for the bug report.
>> Can you try loading the latest version for the code of the tutorial.
>>> I
>> fixed the deprecation warning.
>> 
>> Let us know if you encounter any other issues.
>> 
>> Cheers,
>> Andrei
>> 
>> On Sun, Feb 17, 2019 at 6:49 PM Richard Kenneth Eng <
> 
>> horrido.hobbies@
> 
>>> wrote:
>> 
>>> I'm following the tutorial in the MemoryGame booklet. When I run
>>> the
> game
>>> and click on any square, I get:
>>> 
>>> The method BlBaseAnimation>>#startOn: called from
>>> MgCardElement>>#onFlippedFace has been deprecated.
>>> Use BlElement>>#addAnimation:
>>> 
>>> The tutorial is out of sync. How can I proceed?
>>> 
>>> Is there another way to learn how to use Bloc?
>>> 
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 
> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>> 
>>> 
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--
www.feenk.com

"We are all great at making mistakes."

Re: [Pharo-users] [ANN] P3 version 1.2

[Tudor Girba]

Thanks a lot for doing this!

It is of great help to know that we can reliably work with Postgres.

Cheers,
Doru


> On Feb 12, 2019, at 3:22 PM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> There is a new release of P3, the modern, lean and mean PostgreSQL client for 
> Pharo.
> 
> https://github.com/svenvc/P3
> 
> Version 1.2 contains the following changes:
> 
> - P3PreparedStatement is now joined by a polymorphic P3FormattedStatement 
> working client side on text strings
> - P3PreparedStatement & P3FormattedStatement now share the same double 
> dispatch mechanism to process argument binding
> - Added convenience methods #listDatabases #listSchemas & 
> #listTablesInSchema: to P3Client
> - Added convenience methods #firstColumnData & #firstFieldOfFirstRecord to 
> P3Result
> - Added dynamic ENUM support via #loadEnums in P3Client
> - Add support for the 7 geometric types POINT, CIRCLE, LINE, LSEG, POLYGON & 
> PATH with corresponding objects P3Point, P3Circle, P3Line, P3LineSegment, 
> P3Polygon & P3Path
> - Add support for the INTERVAL type with P3Interval object
> - Added P3Client>>#serverVersion accessor
> - Add support for BIT & VARBIT types with P3FixedBitString & P3BitString 
> objects
> - Add TIMETZ support
> - Organised P3 package with tags
> - More & better documentation & unit tests
> 
> https://github.com/svenvc/P3/releases/tag/v1.2
> 
> The quality of open source software is determined by it being alive, 
> supported and maintained.
> 
> The first way to help is to simply use P3 in your projects and report back 
> about your successes and the issues that you encounter. You can ask questions 
> on the Pharo mailing lists.
> 
> Enjoy,
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 

--
www.feenk.com

"What is more important: To be happy, or to make happy?"

Re: [Pharo-users] PetitParser question

[Tudor Girba]

Great. I am happy you found a solution :)

Cheers,
Doru


> On Jan 30, 2019, at 3:37 PM, Konrad Hinsen  wrote:
> 
> Tudor Girba  writes:
> 
>> Would this not work:
> 
> It works. And as much as I hate to admit it, my version of yesterday was
> very similar except ... that it lacked a set of parentheses :-(
> 
>> Please note that I used PetitParser2 for this one because it also
>> addresses the failure message issue you raised below. However, the
>> logic would work in PP1 as well.
> 
> It does, but I ended up switching to PP2 as well to get the right error
> messages.
> 
> Thanks a lot,
>  Konrad.

--
www.feenk.com

"We cannot reach the flow of things unless we let go."

Re: [Pharo-users] PetitParser question

[Tudor Girba]

Hi,


> On Jan 29, 2019, at 7:04 PM, Konrad Hinsen  wrote:
> 
> Tudor Girba  writes:
> 
>> But, does it solve your problem?
> 
> Not yet. Not sure it will.

Would this not work:

p := (#digit asPParser separatedBy: ($+ asPParser / $- asPParser) trim) ==> 
[:tokens | 
| result |
result := tokens.
2 to: tokens size - 1 by: 2 do: [ :index | 
(tokens at: index) = (tokens at: 2)
ifFalse: [result := PP2Failure message: 'expected ', 
(tokens at: 2) asString, ' but got ', (tokens at: index) asString ]].
result ].


p end parse: '1+3+2 - 6' "a PP2Failure: 'expected + but got -‘"
p end parse: '1+3+2 + 6'  "#($1 $+ $3 $+ $2 $+ $6)”

?

Please note that I used PetitParser2 for this one because it also addresses the 
failure message issue you raised below. However, the logic would work in PP1 as 
well.


Cheers,
Doru



>>> More generally, there seems to be a bug in how PetitParser handles
>>> PPFailure return values. The actually reported error is always different
>>> from what is passed to PPFailure. I love software ;-)
>> 
>> What do you mean?
> 
> If I return
> 
>PPFailure message: 'whatever' at: 0
> 
> from my parser, then it does fail but it reports a different error.
> 
> After some more experiments, it looks like this is perhaps not a bug,
> but a feature that makes returning failures not so useful after all. I
> suspect that PetitParser simply backtracks after my failure and tries a
> different rule that then fails as well.
> 
> A simple example:
> 
>   | p |
>   p := #digit asParser plus flatten
>   ==> [ :value | value asSet size = 1 ifTrue: [ value ] ifFalse: 
> [ PPFailure message: 'not equal' at: 0 ]].
>   p parse: '22233'
> 
> The reported failure is "digit expected at 5".
> 
> On the other hand, if there is no path for backtracking, the reported
> failure is the expected one:
> 
>   | p |
>   p := (#digit asParser, #digit asParser) flatten
>   ==> [ :value | value first = value second ifTrue: [ value ] 
> ifFalse: [ PPFailure message: 'not equal' at: 0 ]].
>   p parse: '23'
> 
> Konrad.

--
www.feenk.com

"Quality cannot be an afterthought."

Re: [Pharo-users] PetitParser question

[Tudor Girba]

Hi,


> On Jan 29, 2019, at 6:31 PM, Konrad Hinsen  wrote:
> 
> Hi Doru,
> 
> Thanks for pointing out the use case in XML, which gave me an
> opportunity to play around with this with almost no
> effort. Unfortunately there seems to be a bug in how PPXmlParser
> constructs the PPFailure message
> (freshly reported:
> https://github.com/moosetechnology/PetitParser/issues/38).

Yes, I saw it. I mostly pointed you to the example. We originally built 
PPXmlParser as an example, and not so much as a production parser.

But, does it solve your problem?

> More generally, there seems to be a bug in how PetitParser handles
> PPFailure return values. The actually reported error is always different
> from what is passed to PPFailure. I love software ;-)

What do you mean?

Cheers,
Doru

> Konrad.

--
www.feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

Re: [Pharo-users] PetitParser question

[Tudor Girba]

Hi Konrad,

A somewhat similar issue is present in an XML grammar: the closing element must 
match the opening element. In PPXmlGrammar, you have a condition that matches 
it and throws a failure otherwise:

element
"[39]   element::=   EmptyElemTag | STag content 
ETag"

^ $< asParser , qualified , attributes , whitespace optional , ('/>' 
asParser / ($> asParser , content , [ :stream | stream position ] asParser , 
' asParser)) ==> [ :nodes | 
nodes fifth = '/>'
ifTrue: [ Array with: nodes second with: nodes third 
with: #() ]
ifFalse: [
nodes second = nodes fifth fifth
ifTrue: [ Array with: nodes second 
with: nodes third with: nodes fifth second ]
ifFalse: [ PPFailure message: 'Expected 
' context: nil at: nodes fifth third ] ] ]

Cheers,
Doru


> On Jan 27, 2019, at 4:38 PM, Konrad Hinsen  wrote:
> 
> Dear Tomo,
> 
>> This post might help you. In case of PetitParser2, it's PP2Failure instead
>> of PPFailure.
>> https://stackoverflow.com/questions/15371334/how-can-a-petitparser-parse-rule-signal-an-error
> 
> That's indeed a possible solution: parse for arbitrary operators, and then 
> add a test for equality that can make everything fail in the end. I will try 
> it out!
> 
> Thanks,
>  Konrad.
> 
> 

--
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

[Pharo-users] pharo announcement in heise.de

[Tudor Girba]

Hi.

I just stumbled across this:
https://www.heise.de/developer/meldung/Programmiersprache-Pharo-7-0-tauscht-zahlreiche-Komponenten-aus-4285162.html

Very cool :)

Doru


--
www.feenk.com

"You can inspect and adapt only what is explicit."

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0 released!

[Tudor Girba]

Great work! Thanks everyone for all the effort!

Doru


> On Jan 22, 2019, at 2:36 PM, Esteban Lorenzano  wrote:
> 
> Pharo 7.0 released!
> ===
> 
> Dear World and dynamic language lovers: 
> 
> The time has come for Pharo 7.0!
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> 
> 
> This is our most significant release yet. Here are the key highlights of this 
> release:
> 
>   • Pharo is now provided in 64-bit version in Linux and OSX and brings 
> even better performance and stability. The 64-bit version is now recommended 
> for Linux and Mac, and is provided as technical preview for Windows.
>   • Pharo comes with a new version of the PharoLauncher 
> (https://pharo.org/download): THE tool to manage your distributions (access 
> to regular versions, jenkins builds, and older versions). 
>   • Pharo build has a fully new build process that supports its full 
> bootstrap from sources. This will enable the production to specific (micro) 
> images. 
>   • Iceberg, the git client for Pharo has been significantly improved, 
> and is the default CMS.
>   • Calypso, the angular stone of PharoThings, is the new system Pharo 
> browser. It replaces Nautilus and brings better remote working and more 
> advanced browsing capabilities. 
>   • IoT is now an important part of Pharo. Installing PharoThings 
> (https://github.com/pharo-iot/PharoThings) provides an impressive amount of 
> tools to develop applications in small devices.
>   • The unified foreign function interface (UnifiedFFI) for interfacing 
> with the outside world is significantly improved to work properly on Windows 
> 64-bit. 
> 
> Pharo 70’s new infrastructure and process set the stage for a new generation 
> of version. 
> The visibility of GitHub combined with the powerful tools that have been 
> validated with more than one year of beta testing is massively pay off.
> 
> These are just the more prominent highlights, but the details are just as 
> important. 
> 
> We have closed a massive amount of issues: 2142 issues! (A comprehensive 
> changelog can be found at: 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo70ChangeLogs.md).
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 7.0 image was 
> contributed by more than 75 people.
> 
> Pharo is more than code. It is an exciting project involving energetic 
> people. We thank all the contributors of this release:
> 
> Gabriel Omar Cotelli, Gustavo Santos, Marcus Denker, Torsten Bergmann, 
> Esteban Lorenzano, Bernardo Ezequiel Contreras, Guille Polito, Pablo Tesone, 
> Yoan Geran, Stéphane Ducasse, Cyril Ferlicot, Vincent Blondeau, Denis 
> Kudriashov, Julien Delplanque, Tim Mackinnon, Max Leske, Andrew P. Black, 
> Tomohiro Oda, Clément Béra, Ben Coman, Eric Gade, Yuriy Tymchuk, Nicolas 
> Cellier, Biyalou-Sama Asbath, Myroslava, Sean DeNigris, Juraj Kubelka, Noury 
> Bouraqadi, Holger Freyther, Geoff Reedy, Norbert Hartl, Paul DeBruicker, 
> Alain Plantec, Martín Dias, Peter Uhnak, Tomohiro Oda, Benoît Verhaeghe, 
> Santiago Bragagnolo, Wouter van Zuilen, Bernhard Pieber, Damien Pollet, Geoff 
> Hill, Hans-Martin Mosner, Ronie Salgado, Philippe Back, Aliaksei Syrel, Dayne 
> Guerra, Rafael Luque, Serge Stinckwich, Vincent Aranega, Hernán Morales 
> Durand, Petr Fischer, Rajula Vineet Reddy, Alexandre Bergel, Esteban A. 
> Maringolo, Jan Blizničenko, Johan Brichau, Luc Fabresse, Quentin Ducasse, 
> Sébastien Roccaserra, Stephan Eggermont, Sven Van Caekenberghe, Takano 
> Mitsuhiro, Pavel Krivanek, Allex Oliveira, Christophe Demarey, Lionel Akue, 
> Nicolai Hess, Martin McClure, Alistair Grant, Pierre Tsapliayev, Milton 
> Mamani, Matteo Marra, Thomas Dupriez, Asbathou Biyalou-Sama.
> (If you contributed with Pharo 7.0 development in any way and we missed your 
> name, please send us a mail and we will add you).
> 
> Enjoy!
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download
> Learn Pharo: http://pharo.org/documentation
> 

--
www.feenk.com

"What is more important: To be happy, or to make happy?"

Re: [Pharo-users] #select was sent to nil

[Tudor Girba]

Thanks for looking into this problem!

Doru


> On Jan 16, 2019, at 10:57 AM, Andrei Chis  wrote:
> 
> The bug seems to have been introduce in 
> Pharo7.0-SNAPSHOT.build.102.sha.3f660fc.arch.64bit by merging the pull 
> request https://github.com/pharo-project/pharo/pull/1847
> 
> On Wed, Jan 16, 2019 at 1:32 AM Hilaire via Pharo-users 
>  wrote:
> Indeed, seems to only happen in a subclass of BlEement.
> 
> Hilaire
> 
> Le 15/01/2019 à 21:33, Andrei Chis a écrit :
> > It happens if you create methods in a class having a superclass with
> > traits. For example if you create a subclass of BlElement you will get
> > this error.
> >
> > What class are you editing when you get this errror?
> >
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.feenk.com

"Some battles are better lost than fought."

Re: [Pharo-users] Search in settings borwser

[Tudor Girba]

Hi,

I would suggest re-downloading the image. Alternatively, you can reload the 
code in a fresh image:
https://gtoolkit.com/#install

Thanks for the feedback on the memory game. We will look at it.

Cheers,
Doru


> On Jan 13, 2019, at 8:03 PM, Hilaire  wrote:
> 
> Nowdays, how do you update your installed image to the latest GToolkit
> version?
> 
> Btw, the Memory game build for Bloc has some issues with latest Bloc
> animation, and may be text, not sure. May be worth fixing.
> 
> Thanks
> 
> Hilaire
> 
> Le 13/01/2019 à 15:55, Tudor Girba a écrit :
>> Thanks for raising the issue. It was due to an incorrectly defined property. 
>> It’s fixed in the latest GToolkit version:
>> https://github.com/feenkcom/gtoolkit/issues/100
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.feenk.com

"You can inspect and adapt only what is explicit."

Re: [Pharo-users] Search in settings borwser

[Tudor Girba]

Hi,

Thanks for raising the issue. It was due to an incorrectly defined property. 
It’s fixed in the latest GToolkit version:
https://github.com/feenkcom/gtoolkit/issues/100

Cheers,
Doru



> On Jan 13, 2019, at 2:18 PM, Hilaire  wrote:
> 
> Hi,
> 
> In latest P7 with GToolkit loaded, when performing a search in the
> settings browser I have an error "#name sent to nil". Anyone notice the
> same problem?
> 
> Btw, in the settings browser I don't find anymore the option to remove
> the critic pane in the class browser?
> 
> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.feenk.com

"Speaking louder won't make the point worthier."

Re: [Pharo-users] [ANN] P3 version 1.1

[Tudor Girba]

Perfect. Then I will continue in our repo and we see later.

Doru


> On Jan 9, 2019, at 9:36 PM, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 7 Jan 2019, at 20:30, Tudor Girba  wrote:
>> 
>> Excellent.
>> 
>> In the meantime, we extended GT4P3 a bit to also navigate Schemas and 
>> Tables' structure.
>> 
>> 
>> For this, I introduced a few classes such as Database, Schema or Table to 
>> ease the inspection and tool creation. It’s a bit naive for now, but it 
>> works quite well. Should these be committed to the P3 directly to enable an 
>> object-oriented API for drilling through the DB?
> 
> Yes, that is what I meant.
> I looked at your code (https://github.com/feenkcom/gt4p3) and I understand 
> the reification.
> But like you say, the usefulness of these objects beyond this exploration is 
> questionable.
> One of the goals of P3 is to be lean and mean, to not offer much framework in 
> how you should make use of it, that should be done by another layer like 
> Glorp.
> We'll see how this evolve going forward.
> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>>> On Jan 6, 2019, at 9:17 PM, Sven Van Caekenberghe via Pharo-users 
>>>  wrote:
>>> 
>>> 
>>> From: Sven Van Caekenberghe 
>>> Subject: Re: [Pharo-users] [ANN] P3 version 1.1
>>> Date: January 6, 2019 at 9:17:34 PM GMT+1
>>> To: Any question about pharo is welcome 
>>> 
>>> 
>>> Nice, I just added convenience methods #listDatabases #listSchemas and 
>>> #listTablesInSchema: to P3Client so you should be able to make a real 
>>> browser, connection >> schemas >> tables >> contents (listDatabases is not 
>>> so useful since you can only connect to 1 database at a time).
>>> 
>>>> On 6 Jan 2019, at 00:01, Tudor Girba  wrote:
>>>> 
>>>> And with a little more code, we now have a dedicated Playground form 
>>>> snippet that opens the database connection without requiring any Pharo 
>>>> code.
>>>> 
>>>> 
>>>> 
>>>> Cheers,
>>>> Doru
>>>> 
>>>> 
>>>>> On Jan 5, 2019, at 12:02 AM, Tudor Girba  wrote:
>>>>> 
>>>>> You can now query a Postgres database from the new GT. The initial code 
>>>>> is available here:
>>>>> https://github.com/feenkcom/gt4p3
>>>>> 
>>>>> It currently looks like this:
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Doru
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I created a new release of P3, the modern, lean and mean PostgreSQL 
>>>>>> client for Pharo.
>>>>>> 
>>>>>> https://github.com/svenvc/P3
>>>>>> 
>>>>>> Version 1.1 contains the following changes:
>>>>>> 
>>>>>> - added support for Postgres Extended Query protocol 
>>>>>> (P3PreparedStatement) (thx Jan @jvdsandt)
>>>>>> - added support for reading array type values (currently INTEGER[] 
>>>>>> FLOAT[] BOOLEAN[] TEXT[] VARCHAR[])
>>>>>> - added P3-Tests package and moved all tests there
>>>>>> - more comments
>>>>>> - more unit tests
>>>>>> 
>>>>>> https://github.com/svenvc/P3/releases/tag/v1.1
>>>>>> 
>>>>>> 
>>>>>> Especially Jan's contribution adds a lot of functionality: the ability 
>>>>>> to work with prepared statements.
>>>>>> 
>>>>>> Here is an example doing a batch insert of 100 records (which is more 
>>>>>> efficient).
>>>>>> 
>>>>>> | client statement |
>>>>>> 
>>>>>> client := P3Client url: 'psql://sven@localhost'.
>>>>>> 
>>>>>> client execute: 'DROP TABLE IF EXISTS table1'.
>>>>>> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at 
>>>>>> TIMESTAMP DEFAULT NOW(), name TEXT)'.
>>>>>> 
>>>>>> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'.
>>>>>> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: 
>>>>>> ('Text #', index printString) ]).
>>>>>> 
>>>>>> client query: 'SELECT * FROM table1'.
>>>>>> client execute: 'DROP TABLE table1'.
>>>>>> 
>>>>>> statement close.
>>>>>> client close.
>>>>>> 
>>>>>> 
>>>>>> Season's Greetings to you all.
>>>>>> 
>>>>>> Sven
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sven Van Caekenberghe
>>>>>> Proudly supporting Pharo
>>>>>> http://pharo.org
>>>>>> http://association.pharo.org
>>>>>> http://consortium.pharo.org
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> www.feenk.com
>>>>> 
>>>>> "What is more important: To be happy, or to make happy?"
>>>>> 
>>>> 
>>>> --
>>>> www.feenk.com
>>>> 
>>>> "Quality cannot be an afterthought."
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> www.feenk.com
>> 
>> "No matter how many recipes we know, we still value a chef."
> 

--
www.feenk.com 

“Live like you mean it."

Re: [Pharo-users] [ANN] P3 version 1.1

[Tudor Girba via Pharo-users]

--- Begin Message ---
Excellent.

In the meantime, we extended GT4P3 a bit to also navigate Schemas and Tables' 
structure.


For this, I introduced a few classes such as Database, Schema or Table to ease 
the inspection and tool creation. It’s a bit naive for now, but it works quite 
well. Should these be committed to the P3 directly to enable an object-oriented 
API for drilling through the DB?

Cheers,
Doru



> On Jan 6, 2019, at 9:17 PM, Sven Van Caekenberghe via Pharo-users 
>  wrote:
> 
> 
> From: Sven Van Caekenberghe 
> Subject: Re: [Pharo-users] [ANN] P3 version 1.1
> Date: January 6, 2019 at 9:17:34 PM GMT+1
> To: Any question about pharo is welcome 
> 
> 
> Nice, I just added convenience methods #listDatabases #listSchemas and 
> #listTablesInSchema: to P3Client so you should be able to make a real 
> browser, connection >> schemas >> tables >> contents (listDatabases is not so 
> useful since you can only connect to 1 database at a time).
> 
>> On 6 Jan 2019, at 00:01, Tudor Girba  wrote:
>> 
>> And with a little more code, we now have a dedicated Playground form snippet 
>> that opens the database connection without requiring any Pharo code.
>> 
>> 
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jan 5, 2019, at 12:02 AM, Tudor Girba  wrote:
>>> 
>>> You can now query a Postgres database from the new GT. The initial code is 
>>> available here:
>>> https://github.com/feenkcom/gt4p3
>>> 
>>> It currently looks like this:
>>> 
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> 
>>>> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I created a new release of P3, the modern, lean and mean PostgreSQL client 
>>>> for Pharo.
>>>> 
>>>> https://github.com/svenvc/P3
>>>> 
>>>> Version 1.1 contains the following changes:
>>>> 
>>>> - added support for Postgres Extended Query protocol (P3PreparedStatement) 
>>>> (thx Jan @jvdsandt)
>>>> - added support for reading array type values (currently INTEGER[] FLOAT[] 
>>>> BOOLEAN[] TEXT[] VARCHAR[])
>>>> - added P3-Tests package and moved all tests there
>>>> - more comments
>>>> - more unit tests
>>>> 
>>>> https://github.com/svenvc/P3/releases/tag/v1.1
>>>> 
>>>> 
>>>> Especially Jan's contribution adds a lot of functionality: the ability to 
>>>> work with prepared statements.
>>>> 
>>>> Here is an example doing a batch insert of 100 records (which is more 
>>>> efficient).
>>>> 
>>>> | client statement |
>>>> 
>>>> client := P3Client url: 'psql://sven@localhost'.
>>>> 
>>>> client execute: 'DROP TABLE IF EXISTS table1'.
>>>> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at 
>>>> TIMESTAMP DEFAULT NOW(), name TEXT)'.
>>>> 
>>>> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'.
>>>> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: 
>>>> ('Text #', index printString) ]).
>>>> 
>>>> client query: 'SELECT * FROM table1'.
>>>> client execute: 'DROP TABLE table1'.
>>>> 
>>>> statement close.
>>>> client close.
>>>> 
>>>> 
>>>> Season's Greetings to you all.
>>>> 
>>>> Sven
>>>> 
>>>> 
>>>> --
>>>> Sven Van Caekenberghe
>>>> Proudly supporting Pharo
>>>> http://pharo.org
>>>> http://association.pharo.org
>>>> http://consortium.pharo.org
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> www.feenk.com
>>> 
>>> "What is more important: To be happy, or to make happy?"
>>> 
>> 
>> --
>> www.feenk.com
>> 
>> "Quality cannot be an afterthought."
>> 
> 
> 
> 
> 

--
www.feenk.com

"No matter how many recipes we know, we still value a chef."








--- End Message ---

Re: [Pharo-users] [ANN] P3 version 1.1

[Tudor Girba]

And with a little more code, we now have a dedicated Playground form snippet 
that opens the database connection without requiring any Pharo code.



Cheers,
Doru


> On Jan 5, 2019, at 12:02 AM, Tudor Girba  wrote:
> 
> You can now query a Postgres database from the new GT. The initial code is 
> available here:
> https://github.com/feenkcom/gt4p3
> 
> It currently looks like this:
> 
> 
> Cheers,
> Doru
> 
> 
> 
>> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe  wrote:
>> 
>> Hi,
>> 
>> I created a new release of P3, the modern, lean and mean PostgreSQL client 
>> for Pharo.
>> 
>> https://github.com/svenvc/P3
>> 
>> Version 1.1 contains the following changes:
>> 
>> - added support for Postgres Extended Query protocol (P3PreparedStatement) 
>> (thx Jan @jvdsandt)
>> - added support for reading array type values (currently INTEGER[] FLOAT[] 
>> BOOLEAN[] TEXT[] VARCHAR[])
>> - added P3-Tests package and moved all tests there
>> - more comments
>> - more unit tests
>> 
>> https://github.com/svenvc/P3/releases/tag/v1.1
>> 
>> 
>> Especially Jan's contribution adds a lot of functionality: the ability to 
>> work with prepared statements.
>> 
>> Here is an example doing a batch insert of 100 records (which is more 
>> efficient).
>> 
>> | client statement |
>> 
>> client := P3Client url: 'psql://sven@localhost'.
>> 
>> client execute: 'DROP TABLE IF EXISTS table1'.
>> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at 
>> TIMESTAMP DEFAULT NOW(), name TEXT)'.
>> 
>> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'.
>> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text 
>> #', index printString) ]).
>> 
>> client query: 'SELECT * FROM table1'.
>> client execute: 'DROP TABLE table1'.
>> 
>> statement close.
>> client close.
>> 
>> 
>> Season's Greetings to you all.
>> 
>> Sven
>> 
>> 
>> --
>> Sven Van Caekenberghe
>> Proudly supporting Pharo
>> http://pharo.org
>> http://association.pharo.org
>> http://consortium.pharo.org
>> 
>> 
>> 
>> 
> 
> --
> www.feenk.com
> 
> "What is more important: To be happy, or to make happy?"
> 

--
www.feenk.com

"Quality cannot be an afterthought."

Re: [Pharo-users] [ANN] P3 version 1.1

[Tudor Girba]

You can now query a Postgres database from the new GT. The initial code is 
available here:
https://github.com/feenkcom/gt4p3

It currently looks like this:


Cheers,
Doru



> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> I created a new release of P3, the modern, lean and mean PostgreSQL client 
> for Pharo.
> 
> https://github.com/svenvc/P3
> 
> Version 1.1 contains the following changes:
> 
> - added support for Postgres Extended Query protocol (P3PreparedStatement) 
> (thx Jan @jvdsandt)
> - added support for reading array type values (currently INTEGER[] FLOAT[] 
> BOOLEAN[] TEXT[] VARCHAR[])
> - added P3-Tests package and moved all tests there
> - more comments
> - more unit tests
> 
> https://github.com/svenvc/P3/releases/tag/v1.1
> 
> 
> Especially Jan's contribution adds a lot of functionality: the ability to 
> work with prepared statements.
> 
> Here is an example doing a batch insert of 100 records (which is more 
> efficient).
> 
> | client statement |
> 
> client := P3Client url: 'psql://sven@localhost'.
> 
> client execute: 'DROP TABLE IF EXISTS table1'.
> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at 
> TIMESTAMP DEFAULT NOW(), name TEXT)'.
> 
> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'.
> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text 
> #', index printString) ]).
> 
> client query: 'SELECT * FROM table1'.
> client execute: 'DROP TABLE table1'.
> 
> statement close.
> client close.
> 
> 
> Season's Greetings to you all.
> 
> Sven
> 
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 

--
www.feenk.com

"What is more important: To be happy, or to make happy?"

Re: [Pharo-users] [ANN] P3 version 1.1

[Tudor Girba via Pharo-users]

--- Begin Message ---
Very cool. Thanks!

Doru


> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> I created a new release of P3, the modern, lean and mean PostgreSQL client 
> for Pharo.
> 
> https://github.com/svenvc/P3
> 
> Version 1.1 contains the following changes:
> 
> - added support for Postgres Extended Query protocol (P3PreparedStatement) 
> (thx Jan @jvdsandt)
> - added support for reading array type values (currently INTEGER[] FLOAT[] 
> BOOLEAN[] TEXT[] VARCHAR[])
> - added P3-Tests package and moved all tests there
> - more comments
> - more unit tests
> 
> https://github.com/svenvc/P3/releases/tag/v1.1
> 
> 
> Especially Jan's contribution adds a lot of functionality: the ability to 
> work with prepared statements.
> 
> Here is an example doing a batch insert of 100 records (which is more 
> efficient).
> 
> | client statement |
> 
> client := P3Client url: 'psql://sven@localhost'.
> 
> client execute: 'DROP TABLE IF EXISTS table1'.
> client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at 
> TIMESTAMP DEFAULT NOW(), name TEXT)'.
> 
> statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'.
> statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text 
> #', index printString) ]).
> 
> client query: 'SELECT * FROM table1'.
> client execute: 'DROP TABLE table1'.
> 
> statement close.
> client close.
> 
> 
> Season's Greetings to you all.
> 
> Sven
> 
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 

--
www.feenk.com

"To utilize feedback, you first have to acquire it."


--- End Message ---

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style

[Tudor Girba via Pharo-users]

--- Begin Message ---
Nice work.

Doru



> On Dec 30, 2018, at 10:13 PM, Stephane Ducasse  
> wrote:
> 
> Hello Fellow Pharoers
> 
> I'm happy to announce a new little book to improve the culture around Pharo.
> I will revise it in the future so you can feel free to send feedback
> and pull requests
> to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle
> 
> Stef
> 
> "The best way to predict the future is to invent" so I do it.
> 

--
www.feenk.com

"To utilize feedback, you first have to acquire it."


--- End Message ---

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba via Pharo-users]

--- Begin Message ---
Hi,

A separate editor is needed when the markup has little resemblance with the 
output, which is the case for HTML. In this case, bidirectional editing, as 
shown in Sketch-n-Sketch, is indeed a very nice thing.

However, in the case of Documenter and the Pillar markup the output is closely 
related to the sources part. In this case, having the two worlds be supported 
seamlessly in the same experience is a huge advantage, especially for 
non-technical people. The interface from Documenter is not trivially possible 
(I for now never saw one like that, and I looked specifically for it) because 
of the prerequisites it needs from underlying graphical framework, but I do 
think it’s a significant step forward in the notebooks space.

Cheers,
Doru



> On Jan 1, 2019, at 8:01 PM, Konrad Hinsen  wrote:
> 
> Hi Offray and Doru,
> 
> allow me to chirp in on a topic that I have been thinking about for a
> while:
> 
>>> Interesting observation. The linked tools as all other notebook
>>> technologies I saw rely on two distinct modes for edit and view that
>>> reside in two distinct widgets (editor and viewer). They do that
>>> because they simply cannot have it in one. Because of the design of
>>> Bloc we are not constrained to that. Instead, we build a seamless
>>> interface that is both optimized for viewing, and for editing with
>>> live preview that does not rely on an explicit render button. This
>>> approach enables direct manipulation without friction, and we think
>>> this is a significant advancement in this space.
> 
>> I don't think is only because other editors can't do it, but because
>> some (most) times you don't want "to conflate two tasks that are
>> /conceptually/ distinct and that, to ensure that people's time is used
>> most effectively and that the final communication is most effective,
>> ought also to be kept /practically/ distinct"[1] which are Composition
>> and typesetting.
> 
> Two remarks.
> 
> First, this is a special case of the more general issue of having
> multiple views and even multiple editors for a single object. No matter
> what you believe to be the best approach to editing text with markup, in
> many other situations it is clearly desirable to have multiple
> views/editors side by side, and I have regretted more than once that
> this doesn't seem to be possible in Pharo's inspector.
> 
> For multiple editors the need to have them side by side is probably more 
> obvious than for mere views, so it may be useful to look at practical
> examples and see how one would realize them in Pharo and/or in GT. One
> of my favorite applications is graphics that are generated by program
> code but can also be edited graphically, as implemented in
> Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/).
> You definitely want the two panes, code and graphics, side by side.
> 
> Second, the example of editing text with markup also illustrates that it
> matters if views are complete (i.e. show all the available data) or
> partial, and if they are invertible, i.e. if a change in an editable
> view can be translated unambiguously into a change in the underlying
> data. Markup with comments, as mentioned by Offray, is a case in which
> the rendered view is partial but nevertheless invertible, so it makes
> sense to have two types of editors, one for the raw markup text and one
> for the rendered version. Some people may want both side by side,
> whereas others may prefer a single one with the possibility to switch,
> depending on how important the non-rendered information is.
> 
> Scientific data visualization provides plenty of interesting examples by
> the way, often with the additional challenge of significant
> computational cost in rendering.
> 
> Konrad.
> 

--
www.feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."


--- End Message ---

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

e, and we think this is 
trivially possible.

About the roadmap, here it is: we aim to build a complete development 
environment that will enable moldable development.

We understand how this can appear vague. I think it’s not because I and my 
colleagues talk about it since many years now. People pay little attention, so 
now we set ourselves to deliver a concrete incarnation of what we think the 
future should look like. We set to create something that does not exist in 
other parts, and we simply do not quite know how this will look like in 
details. For example, we do know that we want to build a Coder or a Debugger, 
we even have advanced ideas and implementations, but we do not know exactly how 
it will look like and because of that we also do not quite know how long it 
will take. We have a particular way of approaching development that relies on 
fast feedback and storytelling, and at the end we always get surprised of where 
the journey takes us. For example, the current state of Documenter was simply 
difficult to imagine even 4 months ago, and in the process we threw away more 
code than is now released. So, we will not detail the concrete steps because we 
do not work like that.

We do have a clear vision of what we think software development should be, and 
we will put forward our guiding principles shortly.

About the governance process: GT is built by feenk and will continue to be so 
for the foreseeable future. We put things that we create in the open, we do so 
for free, and we welcome people to engage with us.


>>  To build this alternative we invested in a whole new stack. That is
>>  not a tiny challenge and getting it right requires many iterations and
>>  feedback. We say we are in alpha not because of inconveniences of
>>  installation but because we are still very much developing the product.
>> 
>> We announced the first alpha version in September and since then much
>> has changed. At present time, we did manage to reach a situation where
>> downloading the distribution should run on Mac, Linux and Windows. 
>> Even so, the current version is only for people that do want to try
>>  knowing that there will be hurdles.
> 
> I think that not only installation inconveniences is related alpha, but
> also this jumping from old GT to new one without a clear migration path
> (as is expected from alpha software and processes). I'm fine with that
> too, but I think that once the new GT reaches beta status the backward
> compatibility should be more important and meanwhile the non regard of
> that should be stated more promptly for previous and future GT users. I
> imagine that, at some point Feenk will provide its users and customers
> with clear support and migration paths regarding its open source
> products (kind of what happens with Canonical and the Long Term Support
> versions of Ubuntu).

As mentioned above, our focus is to build a new experience. It is likely that a 
typical Pharo user will not have much issues adapting to the new interface. A 
developer that depended on the old APIs will be somewhat impacted, but we do 
not expect a too large effort will be required to adopt the new world.

Nevertheless, if it’s stability and predictability you are looking for, it is 
best to wait for now.


>> A word about the user experience. The current version runs inside the
>>  Pharo UI because we need to bootstrap. But, our goal is to build a
>>  complete IDE on the new stack. If you want to judge the user
>>  experience, it is only meaningful to do it within the GT windows, and
>>  not by comparing it with the rest of the existing Pharo UI.
>> 
>>  Does this clarify the situation?
> Yes, it does. It seems that a fork is coming, at least UI wise regarding
> Pharo and new GT, but if the community knows about it, I'm fine with
> that. I think this thread also clarifies what active users of old GT
> will expect from upcoming versions of new (non alpha) GT regarding
> compatibility, open processes, visions and so on. Hopefully we will
> reach that place together.

I do not think a new piece of code should be called a fork. At this point in 
time, GT and everything it comes with, loads cleanly in Pharo 7.

Cheers,
Doru




> On Dec 29, 2018, at 5:10 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi Doru,
> 
> This one is still pending:
> 
> https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html
> 
> Of course we have slow days at end of year and I don't expect immediate
> answer, but now that discussion was active is good to point some pending
> conversation, even to be taken after holidays.
> 
> Cheers,
> 
> Offray
> 
> On 29/12/18 6:38, Tudor Girba wrote:
>> Hi Offray,
>> 
>> I believe I replied to all your emails. If I missed o

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

Hi Offray,

I believe I replied to all your emails. If I missed one, please point me to it.

Cheers,
Doru


> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> 
> On 28/12/18 8:03, Tudor Girba wrote:
>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo  wrote:
>>> 
>>> WOW
>> :)
>> 
>> What part of it do you like?
>> 
>> Cheers,
>> Doru
> 
> And which parts you don't?
> 
> I wrote a long mail regarding good and no so good parts of the new GT
> experience, including features possible forks, that I hope will be
> answered also in detail, to keep the big picture.
> 
> Cheers,
> 
> Offray
> 
> 
> 

--
www.feenk.com

"You can inspect and adapt only what is explicit."

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

> On Dec 28, 2018, at 1:08 PM, Kjell Godo  wrote:
> 
> WOW

:)

What part of it do you like?

Cheers,
Doru


> On Thu, Dec 20, 2018 at 01:57 Tudor Girba  wrote:
> Hi Luke,
> 
> I am happy this looks exciting :).
> 
> About the confusion part: The Glamorous Toolkit we are working on right now 
> is a complete new world built on a complete new graphical stack that does is 
> not based on the existing stack that ships with Pharo. It is not an 
> evolution. It is a leap.
> 
> The goal of the new GT is to propose a completely reshaped programming 
> experience that enables moldable development. You will find the concepts from 
> the old GT in the new world as well. For example, the Inspector is extensible 
> in similar ways and the API is similar as well.
> 
> But, in the new world, we are bringing the concept much further. For example, 
> Documenter provides a whole new kind of a tool that can mold to unify 
> multiple workflows (like data notebooks, code documentation, or tutorials) 
> right in the IDE. Coder provides the infrastructure for manipulating code 
> that can mold its shape as you type. Transcript allows you to embed various 
> widgets to transform the otherwise dull experience of a console into a live 
> one.
> 
> Behind the scenes GT comes with several engines. The Examples engine enables 
> example-driven development which also bridges the gap between testing and 
> documentation effort, especially when combined with Documenter. Releaser is 
> able to release deeply nested projects. Phlow offers an engine that shares 
> similarities with Glamour. Completer provides moldable completion. Visualizer 
> offers a couple of visualization engines such as Mondrian.
> 
> All of these are possible because of the underlying graphical stack made of 
> Sparta/Bloc/Brick.
> 
> All in all, we believe that the new GT enables a new way of programming. 
> Individual features can be attractive, but our goal is to reshape the 
> development experience.
> 
> Does this address the concern?
> 
> Cheers,
> Doru
> 
> 
> > On Dec 19, 2018, at 2:09 PM, Luke Gorrie  wrote:
> > 
> > On Fri, 14 Dec 2018 at 05:13, Tudor Girba  wrote:
> > Please do let us know what you think .. and, of course, what you feel.
> > 
> > I'm feeling excited and confused :).
> > 
> > Excited because I love seeing all these new demos streaming out and I'm 
> > itching to put new capabilities to work.
> > 
> > Confused about the roadmap. How does this "new" Glamorous Toolkit relate to 
> > the "old" one that I learned about last year from the Moldable Tools 
> > thesis? Is this a new version or a complete rewrite? Is it backwards 
> > compatible or completely reimagined? Is adopting the new version a seamless 
> > process or is porting required? Are frameworks like Glamour still there 
> > behind the scenes or were they replaced? etc.
> > 
> > 
> > ___
> > Moose-dev mailing list
> > moose-...@list.inf.unibe.ch
> > https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> --
> www.feenk.com
> 
> "Things happen when they happen,
> not when you talk about them happening."
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

[Tudor Girba]

Hi,

The visualization you describe should be easily doable in the new world.

Did you write the visualization in plain Roassal or with the RTMondrian API?

Cheers,
Doru



> On Dec 28, 2018, at 11:32 AM, Luke Gorrie  wrote:
> 
> Thanks for the explanations!
> 
> I like the separation between selecting (single-click) and spawning 
> (double-click). The miller column panning is indeed working with a two-finger 
> drag on the touchpad. I will need to test whether this gesture works when 
> running GT on Linux and operating it on a Mac via VNC. That's the most common 
> setup for our application.
> 
> Spotter is not urgent for us. I have written some extensions for it but we 
> aren't really using them much yet. If the inspector is working well then 
> that's the main thing.
> 
> I do have one very important Roassal visualization that I need to bring with 
> me smoothly somehow. Question is whether to port if over to the new framework 
> or somehow smoothly embed Roassal in the new GT?
> 
> The visualization is for compile SSA intermediate representation code and 
> looks like this:
> 
> 
> There are some important properties about this diagram:
> 
> - These are two digraphs stacked on top of each other.
> - Nodes are always placed below their parents.
> - Y-position indicates the max number of edges to reach parent nodes.
> - Extra edges (red) can create cycles and should be ignored for layout 
> purposes.
> - Nodes can be compound shapes i.e. colored opcode and optionally fused 
> immediate operands in white.
> - Each node is an object that can be selected and inspected in the next 
> miller column.
> 
> Can this be done in the new framework with similar effort to the old one?
> 
> On Fri, 28 Dec 2018 at 09:46, Tudor Girba  wrote:
> Hi,
> 
> Thanks for the feedback!
> 
> I am happy you like the new possibilities and that you see the incentives to 
> move to the new world :).
> 
> The inspector part is working quite well. The main reason we call it an alpha 
> is because of the missing pieces to get to a full environment.
> 
> You noticed the issue of Spotter. The existing Spotter is the one that is 
> included in the old GT and it lives in the Morphic world. When the focus is 
> in the new inspector, that means that keybindings are handled by Bloc and 
> this is a separate world from Morphic. At present time, we can embed Bloc in 
> Morphic but not the other way around as we want no binding from Bloc to 
> Morphic. For this reason, unhandled keys are not propagated from Bloc to 
> Morphic and that is why pressing Shift+Enter does not open Spotter.
> 
> So, we will have a Spotter, but that will be another implementation. Other 
> unfinished tools are the Debugger and Coder, but these are likely less 
> relevant for your use case.
> 
> A few other missing pieces:
> - some widgets such as a tree are not yet implemented. So, we do not yet have 
> a tree view in inspector.
> - the text editor requires a few enhancements for navigation support.
> - scrollbar
> 
> The Miller-columns interface can be scrolled with the touchpad left-right. 
> Can you confirm?
> 
> About clicking vs double-clicking: Indeed, we now distinguish between 
> selecting and spawning. As soon as there is a page to the right, selecting 
> will populate that page. However, if there is no page to the right, simply 
> selecting in a list will not spawn, like in the old inspector. Like this, you 
> can work on a page without the page scrolling from underneath you. Please 
> note that between pages we have triangles which are actually buttons. 
> Selecting in a list shows a triangle. Clicking on the triangle spawns. So, 
> you can either double-click to spawn, or you can select and then click on the 
> triangle. Once spawned, simple selection is enough. Does this clarify the 
> situation?
> 
> About Roassal: In the new GT we have GtMondrian which is similar to the one 
> from Roassal. We do not yet have support for creating charts (like bar or 
> line charts).
> 
> About the porting strategy: When you have the new GT loaded, the old 
> Inspector will get a _GT pane that will essentially embed the new views in 
> the old inspector. These also allow for interaction. Like this, you can port 
> at your pace and switch only when you are ready.
> 
> Cheers,
> Doru
> 
> 
> 
> > On Dec 27, 2018, at 11:36 AM, Luke Gorrie  wrote:
> > 
> > ... Some comments and questions if I may:
> > 
> > The "+" button to quickly maximize a panel is fantastic. I am often looking 
> > at complex visualizations that should really be full-screen and it was 
> > always too much trouble to "drag" them to full screen and back.
> > 
>

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

Hi,

Thanks for the feedback!

I am happy you like the new possibilities and that you see the incentives to 
move to the new world :).

The inspector part is working quite well. The main reason we call it an alpha 
is because of the missing pieces to get to a full environment.

You noticed the issue of Spotter. The existing Spotter is the one that is 
included in the old GT and it lives in the Morphic world. When the focus is in 
the new inspector, that means that keybindings are handled by Bloc and this is 
a separate world from Morphic. At present time, we can embed Bloc in Morphic 
but not the other way around as we want no binding from Bloc to Morphic. For 
this reason, unhandled keys are not propagated from Bloc to Morphic and that is 
why pressing Shift+Enter does not open Spotter.

So, we will have a Spotter, but that will be another implementation. Other 
unfinished tools are the Debugger and Coder, but these are likely less relevant 
for your use case.

A few other missing pieces:
- some widgets such as a tree are not yet implemented. So, we do not yet have a 
tree view in inspector.
- the text editor requires a few enhancements for navigation support.
- scrollbar

The Miller-columns interface can be scrolled with the touchpad left-right. Can 
you confirm?

About clicking vs double-clicking: Indeed, we now distinguish between selecting 
and spawning. As soon as there is a page to the right, selecting will populate 
that page. However, if there is no page to the right, simply selecting in a 
list will not spawn, like in the old inspector. Like this, you can work on a 
page without the page scrolling from underneath you. Please note that between 
pages we have triangles which are actually buttons. Selecting in a list shows a 
triangle. Clicking on the triangle spawns. So, you can either double-click to 
spawn, or you can select and then click on the triangle. Once spawned, simple 
selection is enough. Does this clarify the situation?

About Roassal: In the new GT we have GtMondrian which is similar to the one 
from Roassal. We do not yet have support for creating charts (like bar or line 
charts).

About the porting strategy: When you have the new GT loaded, the old Inspector 
will get a _GT pane that will essentially embed the new views in the old 
inspector. These also allow for interaction. Like this, you can port at your 
pace and switch only when you are ready.

Cheers,
Doru



> On Dec 27, 2018, at 11:36 AM, Luke Gorrie  wrote:
> 
> ... Some comments and questions if I may:
> 
> The "+" button to quickly maximize a panel is fantastic. I am often looking 
> at complex visualizations that should really be full-screen and it was always 
> too much trouble to "drag" them to full screen and back.
> 
> Is the Spotter still a part of GToolkit? If not then what replaces it? (I can 
> see that it is present in the image but Shift-Return doesn't seem to invoke 
> it when the GTInspector window has focus.)
> 
> Is it still possible to pan left-right between "miller columns"? I see the 
> squares at the top representing panes but clicking and dragging them doesn't 
> seem to do anything.
> 
> How come a double-click is now needed to inspect an object? Is single-click 
> going to have a new function?
> 
> Once more - great work you guys are doing !
> 
> On Thu, 27 Dec 2018 at 11:06, Luke Gorrie  wrote:
> Hi Doru,
> 
> Thank you very much for the detailed explanation.
> 
> I have spent some time with the alpha now. I think it is absolutely fantastic!
> 
> I love the new narrative style of the UI. This ties everything together 
> beautifully and makes it easy to explore. That's really what I am lacking in 
> my application. Currently it simply opens to a blank quasi-playground and it 
> is not obvious what to type or how to get started. I started writing a 
> separate HTML manual but I don't think that's the right medium -- much better 
> with something interactive in the image like the Documenter.
> 
> Just clicking around everything seemed to work basically smoothly for me. 
> Maybe it's already time for me to port over to the new GT? Or what do you 
> think the most likely obstacles would be in transitioning to this alpha 
> version?
> 
> Currently my custom inspector extensions are mostly based on Roassal and 
> List/Tree/Table views. I also have one or two Glamour browsers. Is that all 
> still there in one form or another?
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Every thing has its own flow."

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

[Tudor Girba]

Hi Offray,

Thanks for describing your concerns.

First, let’s address the technical part. Please go to gtoolkit.com and download 
the 64Bit distribution that includes the image and the VM. We will remove the 
standalone image option from the website until the VM situation gets clarified.

Now, a clarification. The old GT was produced over a period of 4 years by an 
open-source team. The project had its own identity, and in 2014 the core of it 
was first integrated in Pharo. I say the core of it, because the visual part 
and other libraries are not in Pharo today. The full potential is found in 
Moose. In any case, during this process, GT got to be identified with Pharo and 
that was a good thing.

The new GT is a product produced by feenk, a company. Much of the original team 
is still active in the new version, but now we commit to our product in a 
different way. The product is free and open-source, but it’s still a product 
with an identity and a goal. At present time, both the team, identity and goal 
are different than those of Pharo.

Our goal is to offer a fundamentally new alternative to program (including 
comparing to what is possible now in Pharo). We are not looking for marginal 
improvements, and we are not aiming at backward compatibility.

To build this alternative we invested in a whole new stack. That is not a tiny 
challenge and getting it right requires many iterations and feedback. We say we 
are in alpha not because of inconveniences of installation but because we are 
still very much developing the product.

We announced the first alpha version in September and since then much has 
changed. At present time, we did manage to reach a situation where downloading 
the distribution should run on Mac, Linux and Windows. Even so, the current 
version is only for people that do want to try knowing that there will be 
hurdles.

A word about the user experience. The current version runs inside the Pharo UI 
because we need to bootstrap. But, our goal is to build a complete IDE on the 
new stack. If you want to judge the user experience, it is only meaningful to 
do it within the GT windows, and not by comparing it with the rest of the 
existing Pharo UI.

Does this clarify the situation?

Cheers,
Doru

--
www.feenk.com

"Every thing has its own flow."

> On 21 Dec 2018, at 23:02, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> I share your feeling of wonder and also concern Luke.
> 
> In my case, I used (old) GT tools to prototype Grafoscopio and now that the 
> PhD thesis is practically done and only dissertation is pending, I would like 
> to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, 
> stability, improved functionality, Iceberg for code management (but 
> supporting Fossil instead of Git).
> 
> I think that there is a lot of possibilities in the new GT tools and I like 
> some of them going into interactive documentation (a line I was trying to 
> explore with Pharo using Grafoscopio). But anytime I tried to use it I 
> stumble upon a stop:
> 
> First time was something related with me having some kind of credential 
> enabled in GitHub to simple use it. I lost a whole morning just enabling that 
> and reporting it. It was related with some mozilla library for font redering 
> that didn't work well at the end.
> Today I tried with the prebuild Linux image and Pharo Launcher, but I got an 
> error message about inability to determine proper VM and when I tried 
> installing it from Pharo 7 I got something related with a 
> MemoryFileWriteStream dependency to be resolved before proper installation.
> I understand that this is alpha software and demos look amazing, but just 
> running them requires a lot of work that previous GT didn't require. 
> This brings me this feeling that these jumps in Pharo put core of the user 
> experience at risk (kind of) and you end wondering how much an old tech will 
> be maintained once the jump to the new shinny stuff is done and which is the 
> migration path.
> 
> In my case, I would like to have something like a Zeroconf script that just 
> takes care of the external libraries, VM and image, to have a real glipmse of 
> the upcoming future, beside the Tweets (which look great BTW). Maybe it will 
> happen in a year or two, once it is properly integrated with Pharo, Zeroconf 
> and thought for "end users" of interactive documents, which don't want to 
> enable GitHub stuff, deal with external rendering dependencies and so on. Now 
> the experience of using GT is kind of hostile for that users.
> 
> Anyway, keep the good work and sharing it. Hopefully at some point it will 
> reach the beta status, where users like myself can use it smoothly and build 
> on GT's promises and interesting features.
> 
> Cheers,
> 
> Offray
>> On 21/12/18 10:59, Luke 

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

And here is the tweet I was mentioning:
https://twitter.com/feenkcom/status/1075011040373551104?s=21

Cheers,
Doru

--
www.feenk.com

"Every thing has its own flow."

> On 21 Dec 2018, at 21:32, Tudor Girba  wrote:
> 
> Hi,
> 
> Thanks for detailing your thoughts.
> 
> Indeed, I know about your application. Whatever you can do with the current 
> GT you will be able to do with the new one.
> 
> Except that for the new one you will be able to do extra things. Here are a 
> few:
> - You can build and share documents that embed those inspector views. This 
> can be useful for reporting or sharing diagnostics with your users.
> - Because the underlying rendering engine is much more powerful, you can 
> express modern and interfaces that integrate with the rest of the environment 
> smoothly.
> - You likely have to deal with log files that might get large. First, the new 
> editor allows you to smoothly work with such files. But, you can go well 
> beyond this. Imagine that you build a tooling that produces the same editor 
> only the text is interactive, and you might even embed visual artifacts right 
> in the text to bridge the gap between what you would see in a typical 
> console. For example, this tweet shows the new Transcript used to debug an 
> animation. For every animation frame, we output the text corresponding with 
> the frame and we insert the graphical preview corresponding to that step.
> 
> You look at GT from the point of view of an end-user. You likely like the 
> fact that you could mold the environment to your context and that you could 
> do this incrementally. It happens that the same principles and tools can be 
> applied to the whole programming, and once you do that, you actually can 
> fundamentally change the act of programming. In fact, the same thing applies 
> to the old GT: we built the new GT using that version and we believe that 
> this allowed us to work much faster than if we would have used more 
> traditional tools. The new GT pushes the envelope significantly further.
> 
> So, that is why we are excited about that perspective, but even if you do not 
> spend much time programming in Pharo, you can still take advantage for the 
> user point of view as described above :).
> 
> Is this answer better?
> 
> Cheers,
> Doru
> 
> 
> 
>> On Dec 21, 2018, at 4:59 PM, Luke Gorrie  wrote:
>> 
>> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  wrote:
>> The goal of the new GT is to propose a completely reshaped programming 
>> experience that enables moldable development. You will find the concepts 
>> from the old GT in the new world as well. For example, the Inspector is 
>> extensible in similar ways and the API is similar as well.
>> [...] 
>> Does this address the concern?
>> 
>> I am not sure yet :).
>> 
>> Programming is not our main use case for GT. We are using GT as an object 
>> inspector (etc) for examining diagnostic data. We have a Smalltalk 
>> application that's similar to GDB and we are using GT as the front-end.
>> 
>> In our world we use the Inspector and the Spotter but all of the Smalltalk 
>> programming views are hidden. GT is "molded" to be a diagnostic tool 
>> *instead of* a programming environment. Specifically, our main use case is 
>> inspecting/debugging the operation of a JIT compiler written in C. We have 
>> Smalltalk code to load binary coredumps from the JIT, decode them using 
>> DWARF debug information, and represent the application-level compiler data 
>> structures as Smalltalk objects. This way we can use GT to browse generated 
>> code, cross-reference profiler data, examine runtime compilation errors, 
>> etc. 
>> 
>> The "old" GT is awesome for this. I feel like this application is also very 
>> much in the spirit of the "moldable tools" thesis. Lots of diagnostic 
>> workflows ultimately boil down to drill-down inspecting and/or searching.
>> 
>> I don't know where we stand with respect to the "new" GT though. I am 
>> talking about diagnostics, you are talking about programming. I am talking 
>> about zeros and ones, you are talking about feelings. I am maintaining a 
>> stable application, you are talking about rewrites. I am having a hard time 
>> whether I should be switching to the new GT in the immediate future, or 
>> waiting another year or two for it to mature, or planning to stick with the 
>> old GT.
>> 
>> Hints would be appreciated :)
>> 
>> I reiterate that I think you guys are doing fantastic work - some of the 
>> most interesting work in the programming universe to my mind. I hope that 
>> this discussion is useful for at least understanding the thought process of 
>> some users / potential users.
>> 
>> Cheers!
>> -Luke
>> 
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> --
> www.feenk.com
> 
> "Being happy is a matter of choice."
> 
> 
> 
> 
> 

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

Hi,

Thanks for detailing your thoughts.

Indeed, I know about your application. Whatever you can do with the current GT 
you will be able to do with the new one.

Except that for the new one you will be able to do extra things. Here are a few:
- You can build and share documents that embed those inspector views. This can 
be useful for reporting or sharing diagnostics with your users.
- Because the underlying rendering engine is much more powerful, you can 
express modern and interfaces that integrate with the rest of the environment 
smoothly.
- You likely have to deal with log files that might get large. First, the new 
editor allows you to smoothly work with such files. But, you can go well beyond 
this. Imagine that you build a tooling that produces the same editor only the 
text is interactive, and you might even embed visual artifacts right in the 
text to bridge the gap between what you would see in a typical console. For 
example, this tweet shows the new Transcript used to debug an animation. For 
every animation frame, we output the text corresponding with the frame and we 
insert the graphical preview corresponding to that step.

You look at GT from the point of view of an end-user. You likely like the fact 
that you could mold the environment to your context and that you could do this 
incrementally. It happens that the same principles and tools can be applied to 
the whole programming, and once you do that, you actually can fundamentally 
change the act of programming. In fact, the same thing applies to the old GT: 
we built the new GT using that version and we believe that this allowed us to 
work much faster than if we would have used more traditional tools. The new GT 
pushes the envelope significantly further.

So, that is why we are excited about that perspective, but even if you do not 
spend much time programming in Pharo, you can still take advantage for the user 
point of view as described above :).

Is this answer better?

Cheers,
Doru



> On Dec 21, 2018, at 4:59 PM, Luke Gorrie  wrote:
> 
> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  wrote:
> The goal of the new GT is to propose a completely reshaped programming 
> experience that enables moldable development. You will find the concepts from 
> the old GT in the new world as well. For example, the Inspector is extensible 
> in similar ways and the API is similar as well.
> [...] 
> Does this address the concern?
> 
> I am not sure yet :).
> 
> Programming is not our main use case for GT. We are using GT as an object 
> inspector (etc) for examining diagnostic data. We have a Smalltalk 
> application that's similar to GDB and we are using GT as the front-end.
> 
> In our world we use the Inspector and the Spotter but all of the Smalltalk 
> programming views are hidden. GT is "molded" to be a diagnostic tool *instead 
> of* a programming environment. Specifically, our main use case is 
> inspecting/debugging the operation of a JIT compiler written in C. We have 
> Smalltalk code to load binary coredumps from the JIT, decode them using DWARF 
> debug information, and represent the application-level compiler data 
> structures as Smalltalk objects. This way we can use GT to browse generated 
> code, cross-reference profiler data, examine runtime compilation errors, etc. 
> 
> The "old" GT is awesome for this. I feel like this application is also very 
> much in the spirit of the "moldable tools" thesis. Lots of diagnostic 
> workflows ultimately boil down to drill-down inspecting and/or searching.
> 
> I don't know where we stand with respect to the "new" GT though. I am talking 
> about diagnostics, you are talking about programming. I am talking about 
> zeros and ones, you are talking about feelings. I am maintaining a stable 
> application, you are talking about rewrites. I am having a hard time whether 
> I should be switching to the new GT in the immediate future, or waiting 
> another year or two for it to mature, or planning to stick with the old GT.
> 
> Hints would be appreciated :)
> 
> I reiterate that I think you guys are doing fantastic work - some of the most 
> interesting work in the programming universe to my mind. I hope that this 
> discussion is useful for at least understanding the thought process of some 
> users / potential users.
> 
> Cheers!
> -Luke
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Being happy is a matter of choice."

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

[Tudor Girba]

Hi Luke,

I am happy this looks exciting :).

About the confusion part: The Glamorous Toolkit we are working on right now is 
a complete new world built on a complete new graphical stack that does is not 
based on the existing stack that ships with Pharo. It is not an evolution. It 
is a leap.

The goal of the new GT is to propose a completely reshaped programming 
experience that enables moldable development. You will find the concepts from 
the old GT in the new world as well. For example, the Inspector is extensible 
in similar ways and the API is similar as well.

But, in the new world, we are bringing the concept much further. For example, 
Documenter provides a whole new kind of a tool that can mold to unify multiple 
workflows (like data notebooks, code documentation, or tutorials) right in the 
IDE. Coder provides the infrastructure for manipulating code that can mold its 
shape as you type. Transcript allows you to embed various widgets to transform 
the otherwise dull experience of a console into a live one.

Behind the scenes GT comes with several engines. The Examples engine enables 
example-driven development which also bridges the gap between testing and 
documentation effort, especially when combined with Documenter. Releaser is 
able to release deeply nested projects. Phlow offers an engine that shares 
similarities with Glamour. Completer provides moldable completion. Visualizer 
offers a couple of visualization engines such as Mondrian.

All of these are possible because of the underlying graphical stack made of 
Sparta/Bloc/Brick.

All in all, we believe that the new GT enables a new way of programming. 
Individual features can be attractive, but our goal is to reshape the 
development experience.

Does this address the concern?

Cheers,
Doru


> On Dec 19, 2018, at 2:09 PM, Luke Gorrie  wrote:
> 
> On Fri, 14 Dec 2018 at 05:13, Tudor Girba  wrote:
> Please do let us know what you think .. and, of course, what you feel.
> 
> I'm feeling excited and confused :).
> 
> Excited because I love seeing all these new demos streaming out and I'm 
> itching to put new capabilities to work.
> 
> Confused about the roadmap. How does this "new" Glamorous Toolkit relate to 
> the "old" one that I learned about last year from the Moldable Tools thesis? 
> Is this a new version or a complete rewrite? Is it backwards compatible or 
> completely reimagined? Is adopting the new version a seamless process or is 
> porting required? Are frameworks like Glamour still there behind the scenes 
> or were they replaced? etc.
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Things happen when they happen,
not when you talk about them happening."

Re: [Pharo-users] [ANN] JSON schema implementation

[Tudor Girba]

Nice work! Thanks!

Doru

> On Nov 22, 2018, at 5:56 PM, Norbert Hartl  wrote:
> 
> JSONSchema
> ===
> 
> This is an implementation of JSON Schema for the pharo language. It is used 
> to define the structure and values of a JSON string and to validate it. The 
> schema itself can be externalized for being consumed by a third party.
> 
> I like to announce the availability of a JSON schema implementation for 
> pharo. As part of my implementation of OpenAPI (which is to be released a bit 
> later) I factored out the JSON schema part into its own repository because I 
> think it is useful. I release it even it is not really finished. Code is 
> mostly undocumented and a lot of features are missing from the full spec. I 
> will improve it slowly and add features as I need them or they being requested
> 
> Hope you like it!
> 
> Norbert 
> 
> 
> 
> The documentation so far (from https://github.com/zweidenker/JSONSchema)
> 
> It can be loaded by downloading it in pharo via
> 
>   Metacello new
> repository: 'github://zweidenker/JSONSchema';
> baseline: #JSONSchema;
> load
> 
> Defining a schema
> -
> 
> These are the expression to create a schema model inside pharo.
> 
> schema := {
>   #name -> JSONSchema string.
>   #dateAndTime -> (JSONSchema stringWithFormat: 'date-time').
>   #numberOfPets -> JSONSchema number } asJSONSchema.
> 
> 
> defines as schema that can parse the following JSON:
> 
> jsonString := '{
>   "name" : "John Doe",
>   "dateAndTime" : "1970-01-01T14:00:00",
>   "numberOfPets" : 3
> }'.
> 
> Reading/Writing a value using a schema
> --
> 
> To parse the value from JSON we only need to invoke:
> 
> value := schema read: jsonString
> 
> The object in value will have name as a string, dateAndTime as a DateAndTime 
> object and numberOfPets as a SmallInteger object.
> 
> The schema can also be used to write out the value as JSON. This is 
> especially useful if we want to ensure that only valid JSON is written. For 
> this invoke
> 
> jsonString := schema write: value.
> 
> Serialize/Materialize a schema
> 
> 
> Addtionally to reading and writing objects a schema can be serialized to 
> string.
> 
> schemaString := NeoJSONWriter toStringPretty: schema.
> 
> gives
> 
> {
>   "type" : "object",
>   "properties" : {
>   "name" : {
>   "type" : "string"
>   },
>   "numberOfPets" : {
>   "type" : "number"
>   },
>   "dateAndTime" : {
>   "type" : "string",
>   "format" : "date-time"
>   }
>   }
> }
> 
> 
> If we would get a schema as string we can instantiate by invoking
> 
> schema := JSONSchema fromString: schemaString.
> 
> Nested schemas
> ---
> 
> Schemas can be nested in any depth. And it can be specified by using the 
> literal Array syntax.
> 
> schema := {
>   #name -> JSONSchema string.
>   #address -> {
> #street -> JSONSchema string.
> #number -> JSONSchema number
>   } } asJSONSchema
> 
> Constraints
> ---
> 
> JSON Schema has a defined set of constraints that can be specified. E.g. for 
> a number the inerval of the value can be specified by
> 
> numberSchema := JSONSchema number.
> numberSchema interval
>   minimum: 1;
>   exclusiveMaximum: 100
> 
> constraining the number value to be greater or equal to 1 and smaller than 
> 100.
> 

--
www.feenk.com

"What is more important: To be happy, or to make happy?"

[Pharo-users] ToManyRelationSlot variant with an ordered collection?

[Tudor Girba]

Hi,

The current implementation of ToManyRelationSlot is based on a RelationSet 
which holds the items in a Set.

Is there an implementation that holds the items in an ordered collection?

Cheers,
Doru


--
www.feenk.com

"Some battles are better lost than fought."

Re: [Pharo-users] New convenience method: ZnClient>>forJsonREST

[Tudor Girba]

This is nice!

Doru


> On Nov 7, 2018, at 5:36 PM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> I added a new convenience method to Zinc HTTP Components: 
> ZnClient>>forJsonREST. This configures a ZnClient (HTTP client) to talk to 
> standard JSON REST web services. Here are a couple of examples:
> 
> ZnClient new
>  forJsonREST;
>  get: 'https://jsonplaceholder.typicode.com/users'.
> 
> What #forJsonREST does is 3 things: set the 'Accept' header to 
> 'application/json', install a #contentReader that parses incoming JSON as 
> well as a #contentWriter that generates JSON.
> 
> ZnClient new
>  systemPolicy;
>  forJsonREST;
>  url: 'https://jsonplaceholder.typicode.com/posts';
>  contents: { #foo->1. #bar->2 } asDictionary;
>  post.
> 
> As you can see, the full ZnClient API can be combined when needed.
> 
> ZnClient new
>  forJsonREST;
>  post: 'https://jsonplaceholder.typicode.com/posts' 
>  contents: (NeoJSONObject new foo: 1; bar: 2; yourself).
> 
> #post:contents: combines separate #url: #contents: and #post message.
> 
> #forJsonREST uses NeoJSON[Object|Writer] if found, else STONJSON. If both are 
> missing, this results in an error.
>   
> ZnClient new
>  systemPolicy;
>  forJsonREST;
>  url: 'http://easy.t3-platform.net/rest/geo-ip';
>  queryAt: #address put: '81.83.7.35';
>  get.
> 
> Finally, here is a more sophisticated example, doing a DNS request over HTTPS:
> 
> ZnClient new
>  systemPolicy;
>  beOneShot;
>  forJsonREST;
>  accept: 'application/dns-json';
>  url: 'https://cloudflare-dns.com/dns-query';
>  queryAt: #name put: 'stfx.eu';
>  queryAt: #type put: #;
>  get.
> 
> Note that in most cases, you will configure one client to a specific endpoint 
> and keep on reusing it. At one point in time it might be good to #close the 
> client (although that happens on finalise as well). For single requests, you 
> can use #beOneShot.
> 
> All this can be found in #bleedingEdge (HEAD). There are unit tests as well.
> 
> Sven
> 
> 

--
www.feenk.com

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo v7.0.0-rc1 released!

[Tudor Girba]

Excellent!

Doru


> On Nov 5, 2018, at 4:11 PM, Esteban Lorenzano  wrote:
> 
> Greetings!
> 
> I’m announcing today we reach Pharo 7.0.0-rc1!
> 
> This is the first step to release a definitive version, and while we will 
> continue integrating bug fixes, API change Pull Requests will be delayed 
> until the open of Pharo 8.0.0 development. 
> Now, you would wonder what is the ChangeLog of this release… and answer is we 
> still do not have one (btw, we should find a way to automate this).
> 
> Anyway… we are very close to release now :)
> 
> Please download, test, report issues.
> 
> Esteban

--
www.feenk.com

"Speaking louder won't make the point worthier."

Re: [Pharo-users] ring deprecation in pharo 7

[Tudor Girba]

Ok. Thanks.

Cheers,
Doru


> On Oct 23, 2018, at 3:30 PM, Pavel Krivanek  wrote:
> 
> Hi,
> 
> the Ring 2 is not integrated because we do not want to have two version in 
> the system at once and we are not ready for the old Ring removal. However, it 
> is marked as deprecated to warn people that they probably should not base 
> their new code on it.
> 
> That is important for more intensive usage of the models. Most people want to 
> simply have something like a method reference. In that case, you can still 
> use the old Ring. We will add some class comments to clarify that.
> 
> Cheers,
> -- Pavel
> 
> út 23. 10. 2018 v 14:41 odesílatel Tudor Girba  napsal:
> Hi,
> 
> Ok.
> 
> So, as Ring2 is not in Pharo 7 and all Ring classes in Pharo 7 are 
> deprecated, should we still use them, or is it desired to load Ring2 in our 
> applications?
> 
> Cheers,
> Doru
> 
> 
> > On Oct 23, 2018, at 9:01 AM, Peter Uhnak  wrote:
> > 
> > Hi Doru,
> > 
> > I imagine the replacement is Pavel's Ring2 
> > https://github.com/pavel-krivanek/ring2
> > 
> > Peter
> > 
> > On Fri, Oct 19, 2018 at 10:56 PM Tudor Girba  wrote:
> > Hi,
> > 
> > Ring seems to be deprecated in Pharo 7. Is there something else it will be 
> > replaced with?
> > 
> > In particular, I am looking for the correct class that should correspond to 
> > RGMethodDefinition.
> > 
> > Cheers,
> > Doru
> > 
> > 
> > --
> > www.feenk.com
> > 
> > "Value is always contextual."
> > 
> > 
> > 
> > 
> > 
> > 
> 
> --
> www.feenk.com
> 
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
> 
> 
> 
> 
> 
> 

--
www.feenk.com

"Beauty is where we see it."

Re: [Pharo-users] ring deprecation in pharo 7

[Tudor Girba]

Hi,

Ok.

So, as Ring2 is not in Pharo 7 and all Ring classes in Pharo 7 are deprecated, 
should we still use them, or is it desired to load Ring2 in our applications?

Cheers,
Doru


> On Oct 23, 2018, at 9:01 AM, Peter Uhnak  wrote:
> 
> Hi Doru,
> 
> I imagine the replacement is Pavel's Ring2 
> https://github.com/pavel-krivanek/ring2
> 
> Peter
> 
> On Fri, Oct 19, 2018 at 10:56 PM Tudor Girba  wrote:
> Hi,
> 
> Ring seems to be deprecated in Pharo 7. Is there something else it will be 
> replaced with?
> 
> In particular, I am looking for the correct class that should correspond to 
> RGMethodDefinition.
> 
> Cheers,
> Doru
> 
> 
> --
> www.feenk.com
> 
> "Value is always contextual."
> 
> 
> 
> 
> 
> 

--
www.feenk.com

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."

[Pharo-users] ring deprecation in pharo 7

[Tudor Girba]

Hi,

Ring seems to be deprecated in Pharo 7. Is there something else it will be 
replaced with?

In particular, I am looking for the correct class that should correspond to 
RGMethodDefinition.

Cheers,
Doru


--
www.feenk.com

"Value is always contextual."

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Tudor Girba]

Hi,

Interesting experiment. Thanks for sharing!

I assume that you tried the original PetitParser. PetitParser2 offers the 
possibility to optimize the parser (kind of a compilation), and this provides a 
significant speedup:
https://github.com/kursjan/petitparser2

Would you be interested in trying this out?

Cheers,
Doru



> On Oct 4, 2018, at 10:46 PM, Steffen Märcker  wrote:
> 
> I gave Xtreams-Parsing and PetitParser a shot and like to share my 
> findings.[*]
> 
> The task was to parse the modelling language of the probabilistic model 
> checker PRISM. I've written a grammer of about 130 definitions in the Xtreams 
> DSL, which is close to Bryan Fords syntax. To avoid doing it all again with 
> PetitParser, I wrote a PetitParserGenerator that takes the DSL and builds a 
> PetitParser.
> 
> The numbers below are just parsing times, no further actions involved. For 
> reference I show the times from PRISM (which uses JavaCC), too -- although 
> they involve additional verification and normalization steps on the AST.
> 
> input  PrismXP   PP   
> 230kB14s9s   2s
> 544kB 121s   20s   5s
> 1.1MB 421s   34s   8s
> 1.4MB  1091s   47s  12s
> 2.2MB  63s  16s
> 2.9MB  81s  20s
> 3.8MB 107s  25s
> 4.4MB 123s  30s
> 
> Please note that these times are not representative at all. It's just a 
> single example and I put zero effort in optimization. However, I am quite 
> satisfied with the results.
> 
> [*] I was already familiar with the DSL of Xtreams-Parsing, which I like very 
> much. I did not consider SmaCC, as I find PEGs easier to use.
> 
> Best, Steffen
> 
> 
> 
> Am .10.2018, 20:14 Uhr, schrieb Steffen Märcker :
> 
>> Dear all,
>> 
>> I have two questions regarding parsing frameworks.
>> 
>> 1) Do you have any insights on the performance of SmaCC VS Xtreams Parsing 
>> VS PetitParser?
>> 2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it worth 
>> the effort?
>> 
>> Sorry for cross-posting, I thought this might interest both communities.
>> 
>> Cheers, Steffen

--
www.feenk.com

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] GLM: preserving columns width in tables // getting the actual column

[Tudor Girba]

Hi,

There is no built-in support for something like this.

You would have to change the internal logic of the TablePresentation renderer.

Cheers,
Doru



> On Oct 4, 2018, at 7:16 PM, Arturo Zambrano  wrote:
> 
> Hi All,
>  I would like to preserve the width of columns for tables after a user has 
> changed them (not fast tables, but it should be similar).
>   To do this I plan to get the actual width of the columns and use it the 
> next time I need to create the table.
>  Please consider the following snippet:
> 
> browser := GLMTabulator new.
> browser row: #Example.
> browser transmit
>   to: #Example;
>   andShow: [ :a | 
>   table:=  a table.
>   table  
> column: 'Class Name' evaluated:[:clazz| clazz name] width:100;
>   column: '# of methods' evaluated:[:clazz| clazz methods 
> size] width:150;
> children:[:clazz| clazz subclasses]; 
> shouldRootsExpand: true ].
>browser openOn: {Object}.  
> 
>  If I resize the columns in the UI and then run
> 
> table columns collect:[:c| c width]   
> 
> I get the original sizes but not the actual ones.
> 
> I have two questions:
>   1- Is there a way to get the actual values for column width?
>   2 - Is there an event that gets fired when column sizes are changed in the 
> UI?
> 
> If there is such an event maybe all that is needed it to update the width 
> inst. var in the columns (GLMTableColumns). 
> 
> TIA
> Arturo
> 
> 
> 
> 

--
www.feenk.com

"From an abstract enough point of view, any two things are similar."

Re: [Pharo-users] GTDocument how to

[Tudor Girba]

Hi,

Please load the whole GT. Also, in the meantime we switched to Tonel which 
should speedup the loading time significantly.

Cheers,
Doru


> On Sep 28, 2018, at 7:53 PM, Tim Mackinnon  wrote:
> 
> When I installed GTDocumenter into a clean P61 image it took a really long 
> time (like 20+ mins), so it may be something you have to wait out.
> 
> It does beg the question why it takes so long? Actually all of our code 
> loading is quite slow compared to other languages that load a lot more code. 
> Not sure if if it’s ever been optimised ?
> 
> Tim
> 
> Sent from my iPhone
> 
>> On 28 Sep 2018, at 05:58, Hilaire  wrote:
>> 
>>> Le 27/09/2018 à 16:52, Juraj Kubelka via Pharo-users a écrit :
>>> 
 On Sep 27, 2018, at 10:41, Hilaire
 >>> > wrote:
 
 Thanks for the tips. Where should be key in this text?
>>> 
>>> What do you mean? You can edit the text as you wish.
>> 
>> Do not forget, what is obvious for one may not be for another. I could
>> write a book full of anecdotes with obvious features in DrGeo not so
>> obvious for a newbie.
>> 
>> So you write this text in playground and inspect?
>> 
>>> 
>>> By evaluating and inspecting: 
>>> 
>>> -=-=-=-
>>> GtDocumenter editorForText: 'This is a Dr. Geo tutorial. Evaluate the
>>> following script:
>>> 
>>> [[[
>>> "A Dr. Geo script that returns DrGeo canvas” 
>>> ]]]
>>> 
>>> Extensions are done using  pragmas.
>>> '
>>> -=-=-=-
>>> 
>>> I have a text editor in an inspector where I can edit the Documenter
>>> content. 
>>> 
>>> 
>>> Do you have the same?
>> 
>> No, never saw that. I installed from:
>> Metacello new
>>   baseline: 'GToolkit';
>>   repository: 'github://feenkcom/gtoolkit/src';
>>   load.
>> 
>>> 
 
 I went installing DrGeo along Documenter in P6.1, but it is stalled when
 installing XML dependecies (a bit old, true).
 
 Conflict with XML? or Issue with DrGeo on P6.1, may be both.
>>> 
>>> How can I install DrGeo? I do not see a Monticello script on the
>>> DrGeo.eu  web page.
>> 
>> I am afraid it is a bit tedious at first as it is not github based, but
>> Launchpad.
>> Read INSTALL file for full instruction:
>> https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/view/head:/src/INSTALL
>> 
>>> 
 
 This is so fragile.
>>> 
>>> Keep in mind that GToolkit, including Documenter, is in alpha version.
>> 
>> I did not have GToolkit in mind when I wrote fragile, more likely the
>> whole Smalltalk things. As I wrote in my previous email, my issue was
>> when installing DrGeo on a P6.1 image with GToolkit already installed. I
>> am not sure about why the process was hanging when installing XML's Dr.
>> Geo requirement. The image is then frozen
>> Ok may be I can't install DrGeo on P6.1, I still have error
>> (screenshot). In the other I failed to installing GToolkit on P7.
>> 
>> Hilaire
>> 
>> -- 
>> Dr. Geo
>> http://drgeo.eu
>> 
>> 
> 
> 

--
www.feenk.com

"Every thing should have the right to be different."

Re: [Pharo-users] To get started with Gtoolkit and bloc

[Tudor Girba]

Hi,

I see where the issue comes from.

The  are like test methods that return an object. That object serves 
as example, but it is not necessarily a user facing object.

Look at the picture below showing BlDragExamples>>#draggableInParent.




BlDragExamples>>#draggableInParent calls several other methods that are marked 
as . In the second pane in the inspector you can see these inner 
methods being unfolded. These examples show how to setup the inner part, and 
how the pieces fit together.

In this case, the outmost example is indeed an element that can be played with 
(you see it here on the third pane), but the inner objects can be as 
interesting through the various custom views.

This way of working replaces testing and bridges the gap with documentation.

You can learn about it here:
https://medium.com/@Chis_Andrei/exemplifying-software-fd39a420472a

Or if you load the full GToolkit, you can follow tutorials live in the 
environment by inspecting:

GtInspector openOn: (GtDocumenter editorForPillar: (IceRepository 
repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 'tutorial' / 
'examples-tutorial.pillar’))

Cheers,
Doru



> On Sep 16, 2018, at 11:08 AM, Hilaire  wrote:
> 
> Le 16/09/2018 à 08:00, Tudor Girba a écrit :
>> The examples are found in methods annotated with . What do you 
>> mean that "Several examples are not actionable”? Could you provide examples 
>> of that to find out what the problem is?
> 
> For examples, in those classes I don't know what to do:
> *
> *BlDragExamples or in categories, Bloc-Example>Events
> 
> These are code you can read, but no clue what to do with it.
> No actionable examples to experiment with to visualize, to edit the code
> in live to learn how this work, etc.
> It looks like the same for most examples.
> 
> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
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."

Re: [Pharo-users] [Demo] Creating Bloc Widgets in Pharo

[Tudor Girba]

It is tested in 6.1. It theoretically should be loadable in 7, too.

Cheers,
Doru


> On Sep 17, 2018, at 8:44 AM, Norbert Hartl  wrote:
> 
> Is Bloc still 6.1 only or can it be tried in pharo 7?
> 
> Norbert
> 
>> Am 17.09.2018 um 06:56 schrieb Tudor Girba :
>> 
>> Indeed, it is ready.
>> 
>> Thanks a lot for playing with it. This is some very cool job!
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>>> On Sep 16, 2018, at 9:08 PM, stephan  wrote:
>>> 
>>> Bloc has improved a lot in the past year. It is ready for your experiments. 
>>> Here is one of mine:
>>> 
>>> https://github.com/StephanEggermont/Presentations
>>> 
>>> Bloc supports the creation of beautiful GUIs,
>>> with nice interactions. This one shows a number
>>> of different ways of using drag-and-drop.
>>> 
>>> https://github.com/StephanEggermont/Presentations
>>> 
>>> A video demonstrating it is at:
>>> 
>>> https://vimeo.com/290163891
>>> 
>>> 
>> 
>> --
>> www.feenk.com
>> 
>> "Every successful trip needs a suitable vehicle."
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

--
www.feenk.com

"Every successful trip needs a suitable vehicle."

Re: [Pharo-users] [Demo] Creating Bloc Widgets in Pharo

[Tudor Girba]

Indeed, it is ready.

Thanks a lot for playing with it. This is some very cool job!

Cheers,
Doru



> On Sep 16, 2018, at 9:08 PM, stephan  wrote:
> 
> Bloc has improved a lot in the past year. It is ready for your experiments. 
> Here is one of mine:
> 
> https://github.com/StephanEggermont/Presentations
> 
> Bloc supports the creation of beautiful GUIs,
> with nice interactions. This one shows a number
> of different ways of using drag-and-drop.
> 
> https://github.com/StephanEggermont/Presentations
> 
> A video demonstrating it is at:
> 
> https://vimeo.com/290163891
> 
> 

--
www.feenk.com

"Every successful trip needs a suitable vehicle."

Re: [Pharo-users] To get started with Gtoolkit and bloc

[Tudor Girba]

Hi,

Thanks for trying.

The examples are found in methods annotated with . What do you mean 
that "Several examples are not actionable”? Could you provide examples of that 
to find out what the problem is?

Cheers,
Doru


> On Sep 15, 2018, at 10:10 AM, Hilaire  wrote:
> 
> Play a bit with the examples. Help me to write some code in the playground
> 
> Several examples are not actionable and seems to be part of some things
> bigger. Am I missing somethings?
> 
> I see this pragma  Is it intended to be search-able from the
> finder or another tool?
> 
> By the way, once Bloc was installed on the image, the image does not
> save. Crash dump included.
> 
> Hilaire
> 
> 
> Le 13/09/2018 à 18:35, Peter Uhnak a écrit :
>> and then in the image itself there is a "Bloc-Examples" package that
>> contains hundreds (thousands?) of examples.
>> 
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.feenk.com

"Don't give to get. Just give."

Re: [Pharo-users] [Moose-dev] [cormas-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

[Tudor Girba]

Hi,

Bloc is a new world and the intention is to build a new stack on it. It can be 
embedded in Morphic, but not the other way around. Higher level frameworks, 
like Spec would have to build a renderer for Bloc.

Cheers,
Doru



> On Sep 6, 2018, at 8:45 PM, Nick Papoylias  wrote:
> 
> Thanx Doru ! 
> 
> Any pointers on embeding Morphs/Specs/RTViews to the 
> new GT tools (and vice versa), if possible ?
> 
> I am looking to achive smth similar to what Johan and Stef did
> on Sec 9.1 of the Spec Book: "Integrating the different UI frameworks",
> but with the Bloc version of GT.
> 
> 
> 
> On Thu, Sep 6, 2018 at 8:24 PM Tudor Girba  wrote:
> Nice job!
> 
> Doru
> 
> 
> 
> > On Sep 6, 2018, at 8:10 PM, Nick Papoylias  wrote:
> > 
> > Some of this tech, will soon make it to Cormas ;)
> > 
> > So we can work together to make it even better !
> > 
> > Best,
> > 
> > Nick
> > 
> > On Thu, Sep 6, 2018 at 7:59 PM Hernán Morales Durand 
> >  wrote:
> > Impressive work!
> > 
> > Congratulations Nick.
> > 
> > Cheers,
> > 
> > Hernán
> > 
> > 2018-09-06 14:17 GMT-03:00 Nick Papoylias :
> > > A nice example of how Pharo can be used for
> > > domain-specific modeling and simulation. Short
> > > session from one of our projects at Rochelle:
> > >
> > > https://www.youtube.com/watch?v=Z7wJNhAIaVQ
> > >
> > > Some additional info here: https://goo.gl/jS4NjB
> > >
> > > Currently investigating how to incorporate the new Bloc based
> > > widgets of @feenkcom into the workflow.
> > >
> > > Cheers,
> > >
> > > Nick
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "cormas-dev" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to cormas-dev+unsubscr...@googlegroups.com.
> > > To post to this group, send email to cormas-...@googlegroups.com.
> > > To view this discussion on the web visit
> > > https://groups.google.com/d/msgid/cormas-dev/CACEStOjqbQt96qeae_4Nsf%3DEBqrQzxZ%3DsNNuwGpk5DWS3W4a3w%40mail.gmail.com.
> > > For more options, visit https://groups.google.com/d/optout.
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "cormas-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to cormas-dev+unsubscr...@googlegroups.com.
> > To post to this group, send email to cormas-...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/cormas-dev/CAKHmnHuSE38ureMsiAO5gHj5AJVzkO0r%3D_cx1JgwnMS%3DmXw%2BtQ%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
> > ___
> > Moose-dev mailing list
> > moose-...@list.inf.unibe.ch
> > https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> --
> www.feenk.com
> 
> "No matter how many recipes we know, we still value a chef."
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the 
software gets."

Re: [Pharo-users] [Moose-dev] [cormas-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

[Tudor Girba]

Nice job!

Doru



> On Sep 6, 2018, at 8:10 PM, Nick Papoylias  wrote:
> 
> Some of this tech, will soon make it to Cormas ;)
> 
> So we can work together to make it even better !
> 
> Best,
> 
> Nick
> 
> On Thu, Sep 6, 2018 at 7:59 PM Hernán Morales Durand 
>  wrote:
> Impressive work!
> 
> Congratulations Nick.
> 
> Cheers,
> 
> Hernán
> 
> 2018-09-06 14:17 GMT-03:00 Nick Papoylias :
> > A nice example of how Pharo can be used for
> > domain-specific modeling and simulation. Short
> > session from one of our projects at Rochelle:
> >
> > https://www.youtube.com/watch?v=Z7wJNhAIaVQ
> >
> > Some additional info here: https://goo.gl/jS4NjB
> >
> > Currently investigating how to incorporate the new Bloc based
> > widgets of @feenkcom into the workflow.
> >
> > Cheers,
> >
> > Nick
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "cormas-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to cormas-dev+unsubscr...@googlegroups.com.
> > To post to this group, send email to cormas-...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/cormas-dev/CACEStOjqbQt96qeae_4Nsf%3DEBqrQzxZ%3DsNNuwGpk5DWS3W4a3w%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "cormas-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to cormas-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to cormas-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/cormas-dev/CAKHmnHuSE38ureMsiAO5gHj5AJVzkO0r%3D_cx1JgwnMS%3DmXw%2BtQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] [Moose-dev] feenk log

[Tudor Girba]

Hi,

Bindings is an issue indeed. They are at the same level as theming and we are 
not at that level yet.

At present time we are focused on showing the breadth of what we can achieve 
with the new infrastructure. We are currently using only the Bloc keybinding 
mechanism (equivalent to Keymapping).

We did explore the use of Commander, but it was not a match for our initial 
work. This does not mean that it’s not a good library. Just that we are still 
exploring and still need to learn what we need. Our focus is on an 
infrastructure for actions that is as close as possible to Bloc, and to figure 
out which parts need to go at which level of abstraction.

Cheers,
Doru



> On Aug 17, 2018, at 5:14 PM, Stéphane Ducasse  
> wrote:
> 
> Hi Doru 
> 
> this is great. We are brainstorming to see if and how Commander should be 
> tuned to offer a smoother extensibility. 
> Julien was developing commands for all his spec tools and guille used 
> commander for Iceberg. 
> We plan to have a meeting brainstorming about commands and context when 
> guille is back from vacation (before 
> ESUG). On your side what did you use for the key binding?
> 
> I would like to able to have pluggable binding so that we can have emacs like 
> ctrl a / ctrle …
> 
> Stef
> 
>> On 17 Aug 2018, at 06:47, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> We again got carried away and forgot to update the world about what is up in 
>> our corner. Here is a summary:
>> 
>> --
>> Bloc & Brick
>> --
>> 
>> - Text editor stability has been significantly improved
>> - Improved support for selection in the text editor
>> - Support for typical editing keybindings (copy, cut, paste)
>> - Text editor debuggability:
>> https://twitter.com/feenkcom/status/1024680215379959808
>> https://twitter.com/feenkcom/status/1020768298017992704
>> - The text editor can handle emojis:
>> https://twitter.com/feenkcom/status/1021872214151507968
>> 
>> --
>> GT
>> --
>> 
>> - Inspector
>> We now have an initial version of a working inspector with resizable panes:
>> https://twitter.com/feenkcom/status/1030091849795612672
>> https://twitter.com/feenkcom/status/1030314856736538624
>> It shows a display string for the current object:
>> https://twitter.com/feenkcom/status/1024564065870512129
>> It can handle errors in the definition of views gracefully:
>> https://twitter.com/feenkcom/status/1009174937217720320
>> We now have multiple extensions expressed in the new Inspector:
>> https://twitter.com/feenkcom/status/1024321868566814720
>> https://twitter.com/feenkcom/status/1022393383850008576
>> 
>> - Documenter saw multiple enhancements.
>> We can now resize various previews live:
>> https://twitter.com/feenkcom/status/1002851190475026432
>> https://twitter.com/feenkcom/status/1001407762285375490
>> https://twitter.com/feenkcom/status/1001152789874167808
>> It now relies on the annotation mechanism from Pillar:
>> https://twitter.com/feenkcom/status/1006508725409079298
>> We can now link classes and expand their definition:
>> https://twitter.com/feenkcom/status/1014609460520775681
>> https://twitter.com/feenkcom/status/1029085603948843008
>> The preview of examples can handle errors gracefully:
>> https://twitter.com/feenkcom/status/1022123808524836864
>> We can run examples in place, enabling a smoother tutorial experience:
>> https://twitter.com/feenkcom/status/1028390957023223809
>> We have new documentation expressed in it:
>> https://twitter.com/feenkcom/status/100700881420672
>> 
>> 
>> 
>> Have fun,
>> The feenk team
>> 
>> --
>> www.feenk.com
>> 
>> "Presenting is storytelling."
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."

[Pharo-users] feenk log

[Tudor Girba]

Hi,

We again got carried away and forgot to update the world about what is up in 
our corner. Here is a summary:

--
Bloc & Brick
--

- Text editor stability has been significantly improved
- Improved support for selection in the text editor
- Support for typical editing keybindings (copy, cut, paste)
- Text editor debuggability:
https://twitter.com/feenkcom/status/1024680215379959808
https://twitter.com/feenkcom/status/1020768298017992704
- The text editor can handle emojis:
https://twitter.com/feenkcom/status/1021872214151507968

--
GT
--

- Inspector
We now have an initial version of a working inspector with resizable panes:
https://twitter.com/feenkcom/status/1030091849795612672
https://twitter.com/feenkcom/status/1030314856736538624
It shows a display string for the current object:
https://twitter.com/feenkcom/status/1024564065870512129
It can handle errors in the definition of views gracefully:
https://twitter.com/feenkcom/status/1009174937217720320
We now have multiple extensions expressed in the new Inspector:
https://twitter.com/feenkcom/status/1024321868566814720
https://twitter.com/feenkcom/status/1022393383850008576

- Documenter saw multiple enhancements.
We can now resize various previews live:
https://twitter.com/feenkcom/status/1002851190475026432
https://twitter.com/feenkcom/status/1001407762285375490
https://twitter.com/feenkcom/status/1001152789874167808
It now relies on the annotation mechanism from Pillar:
https://twitter.com/feenkcom/status/1006508725409079298
We can now link classes and expand their definition:
https://twitter.com/feenkcom/status/1014609460520775681
https://twitter.com/feenkcom/status/1029085603948843008
The preview of examples can handle errors gracefully:
https://twitter.com/feenkcom/status/1022123808524836864
We can run examples in place, enabling a smoother tutorial experience:
https://twitter.com/feenkcom/status/1028390957023223809
We have new documentation expressed in it:
https://twitter.com/feenkcom/status/100700881420672



Have fun,
The feenk team

--
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-users] [Moose-dev] Moose Java AST?

[Tudor Girba]

Hi,

There is one in the SmaCC that ships with Moose: JavaParser.

Cheers,
Doru



> On Jul 31, 2018, at 10:44 AM, Peter Uhnák  wrote:
> 
> Hi,
> 
> is there a Java AST parser in Pharo?
> 
> I imagine that jdt2famix must have something inside, but as far as I 
> understand, it just extracts some information from the source code and throws 
> the AST away.
> 
> Thanks,
> Peter
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

Re: [Pharo-users] The cool implication of gtDocumentor gluing examples and how we might augment source naviagation

[Tudor Girba]

Hi Tim,

Thanks a lot for the detailed comments! More inline.


> On Jun 26, 2018, at 2:57 PM, Tim Mackinnon  wrote:
> 
> Hi Doru - I’ll comment inline below:
> 
>> On 26 Jun 2018, at 13:05, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>>> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon  wrote:
>>> 
>>> Hi guys - not sure how many people noticed this, but at the end of the 
>>> tutorial for gtDocumentor, there is a section on Examples as Documentation.
>> 
>> Thanks for going through the tutorial. Quick questions:
>> - how did it feel to go through it?
>> - did applying changes work fine for you?
>> - was there any confusion about what happened and where you were in the 
>> tutorial?
>> - anything missing that might have helped?
> 
> Going through the tutorial felt reasonably intuitive (I have sort of seen 
> people use Jupyter from afar, so I guess I had an idea of what it was trying 
> to do)
> 
> I did notice that when I click on the Apply buttons, the change to “Applied” 
> was a bit subtle - particular if you scroll back to see if you missed a step. 
> So not sure if colouring the applied buttons or having some kind of Tick 
> might make it a bit more obvious (but it wasn’t that bad)

Ok.

> Applying the changes seemed to work fine - sometimes examples took a bit of 
> time, (but there is the progress indicator top left - although I was looking 
> at the button that I clicked, so maybe some subtle feedback there might help 
> as well)

Ok.

> I didn’t really get confused - however I will confess I only superficially 
> followed along and didn’t question any of what it was telling me (e.g. what 
> methods actually got created etc.). But conceptually it felt compelling and I 
> believed it. 

This is great!

> I did find it a little bit sluggish to scroll (on a MacBook Pro 13” 2015 16gb 
> ram) - so sometimes I over scrolled  - I also kind of missed having a proper 
> scrollbar in the window to help me understand how far down I was. I already 
> mentioned the diff pane scrolling issue. Also, only being able to resize 
> output boxes down was sometimes a bit frustrating (but workable)

What do you mean by only being able to resize down? You should be able to 
resize them up as well. Or did I misunderstand?

> I wasn’t clear on whether I was supposed to be able to edit the markup myself 
> while reading - e.g. putting * around some text didn’t make it bold (I kind 
> of thought it might - but maybe that’s not supported?)

Bold is not added in the highlighter. Indeed, what you see is a live editor so 
editing is intended. However, we still have a few issues with it. While they 
are small, the experience can appear brittle at the moment.
 
> When I click on the + or - magnifying glasses, I also can’t scroll anymore 
> (so its not like a zoom level - but again maybe this is just how its supposed 
> to work? - clicking circle/square icon put it back to 100% and it worked 
> fine).

Thanks. We have to update those.

> Before I loaded the full gToolkit, I did get some messages about things being 
> undefined - but the example still worked and I understood I needed to load 
> something else (and hence asked you here).

Ok.

> Something that did cross my mind (and this was something I questioned about 
> Jupyter) - if you want to reuse intermediate results - as in assign a script 
> result to a variable and then reference later down in your text (like when 
> doing a math’s problem) - it wasn’t clear if that is possible and obvious. 
> Something like 
> 
> X := ${example:GtExamplesTutorial>>#createFileInMemory}$
> And then you talk about X and then demonstrate something like (making use of 
> X):
> 
> ${example:GtExamplesTutorial>>#selectUppcaseLinesFrom: X}$
> I’m guessing you can hide it all in the image with global variables - but I 
> was thinking about how we auto define variables in the playground, and then 
> incorporating those in the narrative.

The document already provides an out variable with the output of the previous 
snippet, and and outs variable with all results. However, we do want to extend 
this a bit more. For example, if you define a variable in a script, that 
variable will be usable in other snippets throughout the document.

Indeed, we can bring the narrative significantly further than it is now.

> Anyway I was very impressed (as was the group at UK Smalltalk) - there is 
> lots of legs in this.

Thanks!

> Tim
> 
> P.s. It was cool that the inspectors work and jump into the gtInspector 
> stuff. I wasn’t clear on what all the different tabs are - maybe of which are 
> similar (_Pillar vs _GT) - but I assume this is just the WIP nature of it. I 
> did also get a few talkbacks clicking on items in the inspecto

Re: [Pharo-users] The cool implication of gtDocumentor gluing examples and how we might augment source naviagation

[Tudor Girba]

Hi,

> On Jun 26, 2018, at 1:16 PM, Tim Mackinnon  wrote:
> 
> Hi guys - not sure how many people noticed this, but at the end of the 
> tutorial for gtDocumentor, there is a section on Examples as Documentation.

Thanks for going through the tutorial. Quick questions:
- how did it feel to go through it?
- did applying changes work fine for you?
- was there any confusion about what happened and where you were in the 
tutorial?
- anything missing that might have helped?


> What is neat (and easily missed) is how when an example references another - 
> there is a little triangle you can toggle to expose that example inline. (See 
> photo).
> 
> This isn’t a completely new ideas (didn’t Newspeak hopscotch do this?) but 
> its very well done in gtDocumentor and this implication could be that if our 
> code editors had this too - then its very handy to unfold code to understand 
> it in one place without having to open new windows. (I still think there are 
> times when you may want to do that - particularly for long chains of 
> methods?) but its certainly an idea that I would be very receptive to having 
> in our code browsers (heck - give me all of gtDocumentor in our source 
> editors).

This actually a new take on the nature of an editor. Hopscotch did not allow 
expanding things inside the text editor. The editor was always a leaf, and it 
is so in all editors I have seen so far. In our case, the triangle is added 
live by the syntax highlighter. Right now, we only use it for navigating 
examples both because we needed to explore how we can make deeply nested 
examples simple to reason about, and because we wanted to validate the Bloc 
architecture.

Of course, this ability is usable in many different ways. For example, the 
embedding in Pillar of various artifacts is done using the same mechanisms. And 
I think you will start seeing all sorts of applications in the UI area that you 
will simply not see in other places.


> I’m wondering what others thing of this? Perhpas not for Pharo 7 - but Pharo 
> 8 (pretty please?)
> 
> Tim
> 
> p.s. Note to @feenk, as its the last example its incredibly tricky to expand 
> it to actually see it well as you can’t scroll further down to then drag the 
> window bigger. I had to add a lot of Cr’s to make some space to do this.

Thanks. Indeed, the resizer solution you see now is just a first attempt 
without much polishing.


Cheers,
Doru


> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tudor Girba]

Hi,

Thanks for trying it out.

I never encountered the issue you mentioned. However, the red cross appears due 
to a Morphic-related problem, not a Bloc one.

Cheers,
Doru



> On Jun 26, 2018, at 11:44 AM, Tim Mackinnon  wrote:
> 
> Hi - yes, doing the Reset Bloc did fix the problem and I can run both 
> examples (and it doesn’t appear to break after running one or the other). 
> HOWEVER - after the reset, when I ran the example with the Mondrian views - 
> right near the beginning where it opens a Pharo browser - the GTDocumentor 
> window turned red with a cross (Note: I had done inspect on the example vs. a 
> playground so I could have a bigger window. I only now noticed that the 
> playground doesn’t use a splitter to let you resize its panes?). 
> 
> I had to close my document and try it again - and this time it was fine - but 
> obviously something broke in the sequence of events.
> 
> Tim
> 
>> On 26 Jun 2018, at 06:02, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> It looks like something broke in your Bloc. You can reset Bloc from the 
>> world menu / Bloc / Reset Bloc. Please let me know if it works.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jun 26, 2018, at 12:54 AM, Tim Mackinnon  wrote:
>>> 
>>> Hi - so I managed to load up the full monty gtDocumentor into an image (a 
>>> few false starts as it you try and load the full monty on top of just 
>>> gtDocumentor e.g in a clean image load
>>> 
>>> Metacello new
>>>  baseline: 'GToolkit';
>>>  repository: '
>>> github://feenkcom/gtoolkit/src
>>> ';
>>>  load.
>>> 
>>> On top of this
>>> Metacello new
>>>  baseline: 'GToolkitDocumenter';
>>>  repository: '
>>> github://feenkcom/gtoolkit-documenter/src
>>> ';
>>>  load.
>>> 
>>> 
>>> It never completes - I gave up after 30 minutes and whining fans on a 
>>> MacBook Pro.
>>> 
>>> Anyway - in a completely clean image I loaded just GTookkit and then run
>>> 
>>> GtDocumenter editorForText: BrToggleExamples comment.
>>> 
>>> Which seemed to work fine - and showed me some buttons with different dots 
>>> on them.
>>> 
>>> So then I went and tried the example I really wanted to see:
>>> 
>>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 
>>> 'doc' / 'tutorial' / 'examples-tutorial.pillar’. 
>>> 
>>> And it just gives a blank tab in the _Pillar, _Contents and _GT tabs? The 
>>> contents tab does show me pillar text unrendered.
>>> 
>>> Interestingly, If I then go back to the previous editorForText example, 
>>> that did work - it now also also show the same blank tabs. So it seems that 
>>> something get broken?
>>> 
>>> This is on OSX with the a 64bit image - labelled 6.1 - 64bit (tech preview) 
>>> - so the current stable pharo for 64 bit.
>>> 
>>> Is this a known issue?
>>> 
>>> Tim
>>> 
>>> 
>>>> On 20 Jun 2018, at 02:53, Tim Mackinnon  wrote:
>>>> 
>>>> Actually I realised it ended up on the be moose forum - here’s what Doru 
>>>> replied (for any lurkers)
>>>> 
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>>> On Jun 18, 2018, at 1:21 PM, Tim Mackinnon  wrote:
>>>>> 
>>>>> Guys this is really impressive!
>>>> 
>>>> Thanks.
>>>> 
>>>> 
>>>>> 2 things I noticed when going through the example in a new Pharo 6.1 
>>>>> image (with the latest Iceberg) -
>>>>> 
>>>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>>>> be worth a note in the readme (I’ll submit a PR)
>>>> Show Quoted Content
>>>>> 2 things I noticed when going through the example in a new Pharo 6.1 
>>>>> image (with the latest Iceberg) -
>>>>> 
>>>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>>>> be worth a note in the readme (I’ll submit a PR)
>>>> 
>>>> Ok.
>&

Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tudor Girba]

Hi,

It looks like something broke in your Bloc. You can reset Bloc from the world 
menu / Bloc / Reset Bloc. Please let me know if it works.

Cheers,
Doru


> On Jun 26, 2018, at 12:54 AM, Tim Mackinnon  wrote:
> 
> Hi - so I managed to load up the full monty gtDocumentor into an image (a few 
> false starts as it you try and load the full monty on top of just 
> gtDocumentor e.g in a clean image load
> 
> Metacello new
>baseline: 'GToolkit';
>repository: '
> github://feenkcom/gtoolkit/src
> ';
>load.
> 
> On top of this
> Metacello new
>baseline: 'GToolkitDocumenter';
>repository: '
> github://feenkcom/gtoolkit-documenter/src
> ';
>load.
> 
> 
> It never completes - I gave up after 30 minutes and whining fans on a MacBook 
> Pro.
> 
> Anyway - in a completely clean image I loaded just GTookkit and then run
> 
> GtDocumenter editorForText: BrToggleExamples comment.
> 
> Which seemed to work fine - and showed me some buttons with different dots on 
> them.
> 
> So then I went and tried the example I really wanted to see:
> 
> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' 
> / 'tutorial' / 'examples-tutorial.pillar’. 
> 
> And it just gives a blank tab in the _Pillar, _Contents and _GT tabs? The 
> contents tab does show me pillar text unrendered.
> 
> Interestingly, If I then go back to the previous editorForText example, that 
> did work - it now also also show the same blank tabs. So it seems that 
> something get broken?
> 
> This is on OSX with the a 64bit image - labelled 6.1 - 64bit (tech preview) - 
> so the current stable pharo for 64 bit.
> 
> Is this a known issue?
> 
> Tim
> 
> 
>> On 20 Jun 2018, at 02:53, Tim Mackinnon  wrote:
>> 
>> Actually I realised it ended up on the be moose forum - here’s what Doru 
>> replied (for any lurkers)
>> 
>> 
>> 
>> Sent from my iPhone
>>> On Jun 18, 2018, at 1:21 PM, Tim Mackinnon  wrote:
>>> 
>>> Guys this is really impressive!
>> 
>> Thanks.
>> 
>> 
>>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>>> (with the latest Iceberg) -
>>> 
>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>> be worth a note in the readme (I’ll submit a PR)
>> Show Quoted Content
>>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>>> (with the latest Iceberg) -
>>> 
>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>> be worth a note in the readme (I’ll submit a PR)
>> 
>> Ok.
>> 
>> 
>>> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian 
>>> DNU) when you try any of the graphical bits , making me think either the 
>>> dependencies are incorrect  on the Baseline (or the instruction for the 
>>> example also need to mention you need to load something else - presumably 
>>> Roassal?
>> 
>> Indeed, this is due to the fact that loading GToolkitDocumenter does not 
>> load GToolkitVisualizer which includes GtMondrian. We are still working on 
>> finding the right dependencies balance.
>> 
>> Until then, please load the whole GToolkit to get the full support.
>> 
>> 
>>> 3) You can’t scroll the Diff tabs of results, only the Code tabs
>> 
>> Good catch!
>> 
>> 
>> Cheers,
>> Doru
>> 
>> Sent from my iPhone
>> 
>> On 20 Jun 2018, at 02:47, Tim Mackinnon  wrote:
>> 
>>> Bump (not sure this got through , and keen to know how to load the 
>>> diagramming bit)
>>> 
>>> Guys this is really impressive!
>>> 
>>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>>> (with the latest Iceberg) -
>>> 
>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>> be worth a note in the readme (I’ll submit a PR)
>>> 
>>> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian 
>>>

Re: [Pharo-users] [ANN] GNU Dr. Geo release 18.06

[Tudor Girba]

This is great work!

Thanks a lot for pushing this. I know it was not the smoothest transition for 
you, but I think it is a win-win for everyone.

Cheers,
Tudor


> On Jun 22, 2018, at 12:16 PM, Hilaire  wrote:
> 
> We are please to announce the Dr. Geo release 18.06. It follows the release 
> 17.07 in July 2017. 
> A large part of the effort was to port Dr. Geo from the Pharo 3 to Pharo 7 
> Smalltalk development environment. 
> In addition to usual bug fixes several features were added. 
> 
> 
> 
> Mini changelog:
> - Dedicated Script browser 
> - Inspector on Smalltalk Sketch 
> - Positioning zoom 
> - Unit tests based on Smalltalk sketch 
> - Lan share 
> - Graphic user interface theme 
> - Fullscreen option 
> - Lots of bug fixes 
> 
> Read the complete announcement
> 
> Dr. Geo is always looking for volunteers to translate its user interface. 
> 
> Hilaire Fernandes  
> -- 
> Dr. Geo
> 
> http://drgeo.eu

--
www.tudorgirba.com
www.feenk.com

"To utilize feedback, you first have to acquire it."

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg v1.1.1

[Tudor Girba]

Hi,

Indeed. Something went amiss in this email exchange. But, I really do not think 
that you are in disagreement.

Cheers,
Doru



> On Jun 19, 2018, at 4:09 PM, Christophe Demarey  
> wrote:
> 
> Hi Norbert,
> 
>> Le 19 juin 2018 à 14:06, Norbert Hartl  a écrit :
>> 
>> I have no use for an environment where people only care about coding new 
>> cool stuff. If it would be like this I would quit all my pharo businesses, 
>> move to mainstream and would use pharo only for hobbyist projects because 
>> that would be the level that can be met.
> 
> I do not think Guille has this state of mind. He spends time to write lot of 
> tests for code other people wrote (not the funniest part), to clean code in 
> the image (old code, bad dependencies, better API), to improve existing 
> stuff, answering questions on the ML, and so on.
> He is one of the few people that really tries to push semantic versioning. He 
> could have made some errors (like everyone) but I find your sentence not fair 
> for him.
> 
> Regards,
> Christophe

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

[Tudor Girba]

Great work!

Doru


> On Jun 19, 2018, at 3:55 PM, Christophe Demarey  
> wrote:
> 
> Hi all,
> 
> I just released PharoLauncher 1.2. It includes a new windows installer that 
> you can use without administrator privileges as well as binary signing for OS 
> X and Windows. Also, Pharo Launcher is not anymore identified as ‘Pharo’ 
> application and comes with its own icon.
> 
> Here is the changelog (details on 
> https://github.com/pharo-project/pharo-launcher/issues):
> New features:
>   #21 Bless the DMG
>   #46 sign pharo launcher app for windows
>   #103 No way to rename a local template
>   #107 Unable to add a description for the image using the Launcher UI
>   #121 You can't see/sort images by last modified date
> Improvements:
>   #69 Import command should also import pharo-local directory
>   #70 Import command should delete origin folder if empty
>   #73 Managers of Download of VMs and images should be in their own 
> packages
>   #76 Use https instead of http to requests the pharo file server
>   #82 Official Distributions loads 32bit versions on 64bit System (i.e. 
> provide better information on templates architecture)
>   #86 Sort Existing Images Case-Insensitive
>   #98 Copy and subfolders problem (contents no copied)
>   #101 Templates from a local image are listed in "downloaded". "local" 
> would be a better name
>   #102 Template Cleared at Startup setting is enabled, making it weird 
> when trying to use the template feature
>   #106 Import could work if we select the parent folder of an image
>   #109 Use latest pre-Spur VM to determine the image version
>   #122 The Run without settings icon looks like a funny grey/which blob 
> (missing alpha correction)
> Bux fixes:
>   #41 #selectedMorphList was sent to nil
>   #67 bash is not a command usable under windows
>   #68 Does not launch images on Windows
>   #85 Double click on an existing image open a file selector
>   #88 Pharo Launcher on Windows > Failing
>   #104 GUI bug makes Launcher unusable
>   #110 Image launch not reliable on Windows
>   #119 MessageNotUnderstood exception on launch
>   #123 The status bar of the Launcher is broken, so can't easily show 
> image descriptions 
> 
> 
> Big thanks to all contributors: code, issues report, comments, advices.
>   
> You can get platform bundles from pharo download page or files.pharo.org: 
> http://files.pharo.org/pharo-launcher/1.2/
> 
> Regards,
> Christophe.

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."

Re: [Pharo-users] [ann] gt documenter

[Tudor Girba]

Hi,

Moz2D is one of the backends of Sparta, the canvas behind Bloc. The repository 
is here:
https://github.com/syrel/Moz2D

It comes as a VM plugin. When you load Bloc and Sparta, the loading process 
automatically also downloads the plugin and installs it in the VM. On Linux, 
this only works for Pharo 64bit installations.

So, all you would need to do is to take a fresh Pharo 64 image + vm and then 
load:
Metacello new
   baseline: 'GToolkit';
   repository: 'github://feenkcom/gtoolkit/src';
   load.

If it does not work, it would be useful for us to debug that situation.

Good luck with your thesis.

Cheers,
Doru



> On Jun 19, 2018, at 3:26 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> I will (once I have deliver my PhD thesis on upcoming June 25th). There
> is any place where Moz2D installation is documented? Being a such
> integral part of the font rendering capabilities of Documenter I
> couldn't find any place in its documentation dealing with Moz2D as
> prerequisite and addressing its installation.
> 
> Cheers,
> 
> Offray
> 
> 
> On 19/06/18 03:04, Tudor Girba wrote:
>> Hi Offray,
>> 
>> Would you be able to retry the installation as mentioned below, and let us 
>> know if you still encounter issues?
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jun 16, 2018, at 8:24 PM, Tudor Girba  wrote:
>>> 
>>> Hi,
>>> 
>>> If Moz2D is installed, the fonts should work fine.
>>> 
>>> Can you please try the installation again? And if it does not work, please 
>>> let me know if in 
>>> Settings Browser / Appearance / Bloc / Preferable Sparta renderering 
>>> backend
>>> you see Moz2D or not.
>>> 
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>>> On Jun 15, 2018, at 2:31 PM, Offray Vladimir Luna Cárdenas 
>>>>  wrote:
>>>> 
>>>> Hi Doru,
>>>> 
>>>> Thanks for the update in Markdown. I will try to bring better Markdown
>>>> support in Pharo by developing my ideas on a Playground for Markdown
>>>> with syntax highlighting, image preview and so on and maybe I can help
>>>> in incorporating them in GT Documenter on Pharo 7.
>>>> 
>>>> I can confirm that fonts didn't work on Manjaro on 64 bits installation
>>>> running Pharo 64b previously, but maybe in Pharo 7 installation will be
>>>> smoother, including font installation via Moz2D integration (nix package
>>>> manager has been a real asset in our workshops in multiple Unix
>>>> environments, including Mac and several Gnu/Linux flavors, so maybe it
>>>> can help with Moz2D engine and fonts integration).
>>>> 
>>>> Cheers,
>>>> 
>>>> Offray
>>>> 
>>>> 
>>>> On 15/06/18 00:56, Tudor Girba wrote:
>>>>> Hi,
>>>>> 
>>>>> I am happy you like it.
>>>>> 
>>>>> Fonts should work with a Pharo 64b installation on Linux, including 
>>>>> Manjaro. Can you confirm that you use a Pharo 64bit and that it does not 
>>>>> work? If yes, can you describe how you are installing Pharo and GToolkit?
>>>>> 
>>>>> Markdown is certainly interesting, but it is not our focus at this point. 
>>>>> We are building on top of Pillar. There are several reasons for it, two 
>>>>> of them being:
>>>>> 1. To build the experience we want to, we need deep control over the 
>>>>> markup language and Pillar provides that in Pharo.
>>>>> 2. Pillar is the de facto documentation markup used in Pharo, and our 
>>>>> primary focus is to support new kinds of development workflows in this 
>>>>> environment, including handling documentation.
>>>>> 
>>>>> GT 2nd generation will indeed not be part of Pharo 7, but will be 
>>>>> loadable in it.
>>>>> 
>>>>> Cheers,
>>>>> Doru
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna Cárdenas 
>>>>>>  wrote:
>>>>>> 
>>>>>> Cool! I hope to see how this could be integrated in Grafoscopio once 
>>>>>> Documenter is better integrated with Pharo, for example addressing the 
>>>>>> font issues already reported in the mailing list on Manjaro Linux (64 
>>>>>> bits) and in the thread at [1] and also the Markdown integration 
>>

Re: [Pharo-users] [ann] gt documenter

[Tudor Girba]

Hi Offray,

Would you be able to retry the installation as mentioned below, and let us know 
if you still encounter issues?

Cheers,
Doru


> On Jun 16, 2018, at 8:24 PM, Tudor Girba  wrote:
> 
> Hi,
> 
> If Moz2D is installed, the fonts should work fine.
> 
> Can you please try the installation again? And if it does not work, please 
> let me know if in 
>   Settings Browser / Appearance / Bloc / Preferable Sparta renderering 
> backend
> you see Moz2D or not.
> 
> 
> Cheers,
> Doru
> 
> 
>> On Jun 15, 2018, at 2:31 PM, Offray Vladimir Luna Cárdenas 
>>  wrote:
>> 
>> Hi Doru,
>> 
>> Thanks for the update in Markdown. I will try to bring better Markdown
>> support in Pharo by developing my ideas on a Playground for Markdown
>> with syntax highlighting, image preview and so on and maybe I can help
>> in incorporating them in GT Documenter on Pharo 7.
>> 
>> I can confirm that fonts didn't work on Manjaro on 64 bits installation
>> running Pharo 64b previously, but maybe in Pharo 7 installation will be
>> smoother, including font installation via Moz2D integration (nix package
>> manager has been a real asset in our workshops in multiple Unix
>> environments, including Mac and several Gnu/Linux flavors, so maybe it
>> can help with Moz2D engine and fonts integration).
>> 
>> Cheers,
>> 
>> Offray
>> 
>> 
>> On 15/06/18 00:56, Tudor Girba wrote:
>>> Hi,
>>> 
>>> I am happy you like it.
>>> 
>>> Fonts should work with a Pharo 64b installation on Linux, including 
>>> Manjaro. Can you confirm that you use a Pharo 64bit and that it does not 
>>> work? If yes, can you describe how you are installing Pharo and GToolkit?
>>> 
>>> Markdown is certainly interesting, but it is not our focus at this point. 
>>> We are building on top of Pillar. There are several reasons for it, two of 
>>> them being:
>>> 1. To build the experience we want to, we need deep control over the markup 
>>> language and Pillar provides that in Pharo.
>>> 2. Pillar is the de facto documentation markup used in Pharo, and our 
>>> primary focus is to support new kinds of development workflows in this 
>>> environment, including handling documentation.
>>> 
>>> GT 2nd generation will indeed not be part of Pharo 7, but will be loadable 
>>> in it.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> 
>>>> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna Cárdenas 
>>>>  wrote:
>>>> 
>>>> Cool! I hope to see how this could be integrated in Grafoscopio once 
>>>> Documenter is better integrated with Pharo, for example addressing the 
>>>> font issues already reported in the mailing list on Manjaro Linux (64 
>>>> bits) and in the thread at [1] and also the Markdown integration 
>>>> possibilities (which are never answered).
>>>> [1] https://twitter.com/feenkcom/status/996310432225820672
>>>> 
>>>> I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to 
>>>> use it in a more confident day to day fashion.
>>>> 
>>>> Keep the interesting work.
>>>> 
>>>> Cheers,
>>>> 
>>>> Offray
>>>> 
>>>> On 13/06/18 15:57, Tudor Girba wrote:
>>>>> Hi,
>>>>> 
>>>>> We are happy to announce a new leap of GToolkit Documenter, the tool for 
>>>>> manipulating live documents directly in the development environment:
>>>>> https://github.com/feenkcom/gtoolkit-documenter
>>>>> 
>>>>> Documenter is part of the second generation GToolkit project, it is based 
>>>>> on Bloc and works with the latest Pillar. It is mainly developed by Juraj 
>>>>> Kubelka.
>>>>> 
>>>>> Attached you can see a preview of how documents look like:
>>>>> 
>>>>> 
>>>>> 
>>>>> At its core it offers a live editor for manipulating Pillar documents. 
>>>>> The interaction happens seamlessly directly in the text editor, and it 
>>>>> can be combined with different types of previews to serve several classes 
>>>>> of use cases:
>>>>>   • code documentation
>>>>>   • tutorials
>>>>>   • interactive data notebook
>>>>> 
>>>>> 
>>>>> Code documentation
>>>>> 
>>>>> Do

Re: [Pharo-users] Windows installation broken?

[Tudor Girba]

Hi Herbert,

I too invite you to reconsider your language. Please stick to arguments. This 
is a public forum and its communication hygiene depends on everyone’s behavior.

Now, tackling your point: in this specific case, even your argument is 
incorrect. Nobody is forcing you to do anything. Pharo 7 is a development 
version and this is expected to have glitches from time to time. While this is 
inconvenient, pushing new things is the only way to obtain the necessary 
feedback. If you prefer stability, you are welcome to work with 6.1.

Cheers,
Tudor



> On Jun 18, 2018, at 4:47 PM, Herbert Vojčík  wrote:
> 
> 
> 
> Esteban Lorenzano wrote on 18. 6. 2018 16:04:
>>> On 18 Jun 2018, at 15:39, Herbert Vojčík  wrote:
>>> 
>>> 
>>> 
>>> horrido wrote on 18. 6. 2018 0:04:
 This is what concerns me. I don't care that there are workarounds
 (undocumented or hard to find).
 I care that Windows is a most popular development platform. I care that
 newcomers to Pharo easily find what they need to get started. I care about
 Pharo's reputation.
 The last thing Pharo needs is a black eye.
>>> 
>>> Do you have enough balls to call out Steph for his obviously wrong decision 
>>> to push Launcher down the users' throats and make him revert to working 
>>> installers / zips? Cause AFAICT there's the bottleneck atm.
>> First, it was MY decision.
> 
> My apologies to blaming Steph.
> 
>> I’m pushing launcher as the default download for Pharo since year now.
>> Do I am happy with it not working on windows right now? Of course not. But 
>> pushing it also in windows has already forced us to fix some bugs there and 
>> a new version of the launcher (and a better Pharo on windows) and at the 
>> result will be good.
>> I was going to suspend the launcher as the default download until a better 
>> version arrived, but I’ve been told that will happen this week, so I will 
>> wait.
>> Second, we have a lot of bottlenecks, but is true this is important.
>> Third, please restrain your self to talk like that in the future. Is rude 
>> and unnecessary.
> 
> I won't. Sometimes it seems this kind of talk is needed. Windows launcher was 
> not working for so long but it is still pushed as the default download 
> option, because "higher goals" I presume. If this kind of talk helps to get 
> rid of it until working (or make it finally actually work), it is anything 
> but unnecessary.
> 
> Herby
> 
>> Esteban
>>> 
>>> Herby
>>> 
 Travis Ayres wrote
> I wonder how many people tried Pharo, thought "Oh this is totally broken"
> and are never going to give it a second (or third) chance.
> 
> On Sun, Jun 17, 2018 at 11:26 AM,
> phil@
>  
> phil@
> 
> wrote:
> 
>> The current website shows the wrong link, the installer for the bleeding
>> edge is the wrong one in files.
>> The situation on the Windows front is very very bad and not really
>> improving.
>> 
>> That being said, the installer on the CI is the right one and works.
>> 
>> so, steal the installer from here: https://ci.inria.fr/pharo-ci-
>> jenkins2/job/PharoLauncher
>> 
>> This is the one you want:
>> 
>> https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/
>> 
>> For having the latest lastet everything, go to the launcher settings, get
>> into the devmode and open monticello and load the latest packages.
>> 
>> Phil
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tudor Girba]

Hi,

Thanks.

About the next steps: We mostly think in terms of the overall goal, and the 
concrete next steps somehow happen. For us the end goal is a moldable 
environment that integrates all workflows related to development. Documentation 
is one of those development activities that are both pervasive and typically 
disliked, so it is only natural that we want to aim to create a full experience 
for it within the environment. 

What is more interesting to us is that we could create this experience without 
much effort due to the flexibility of the underlying framework. There is still 
engineering work to do, but I think the most difficult part is to rethink the 
way we approach UI given these new abilities.

Cheers,
Doru


> On Jun 17, 2018, at 3:09 PM, Denis Kudriashov  wrote:
> 
> Hi Tudor.
> 
> This is super impressive. 
> What's next? Do you plan to implement IDE for writing documents, navigation, 
> refactorings? (senders, renames should find all places in documents)
> 
> 2018-06-13 21:57 GMT+01:00 Tudor Girba :
> Hi,
> 
> We are happy to announce a new leap of GToolkit Documenter, the tool for 
> manipulating live documents directly in the development environment:
> https://github.com/feenkcom/gtoolkit-documenter
> 
> Documenter is part of the second generation GToolkit project, it is based on 
> Bloc and works with the latest Pillar. It is mainly developed by Juraj 
> Kubelka.
> 
> Attached you can see a preview of how documents look like:
> 
> 
> 
> At its core it offers a live editor for manipulating Pillar documents. The 
> interaction happens seamlessly directly in the text editor, and it can be 
> combined with different types of previews to serve several classes of use 
> cases:
>   • code documentation
>   • tutorials
>   • interactive data notebook
> 
> 
> Code documentation
> 
> Documenter complements the GToolkit Examples engine to redefine code 
> documentation. When practicing example-driven development, examples get 
> written as part of the typical development. Once examples exist, they can be 
> quickly put together in a document to form documentation. For example, the 
> linked picture shows the comment of a class containing a visual explanation:
> https://twitter.com/feenkcom/status/973899862482866176
> 
> You can see a live example of documentation by inspecting the following 
> snippet:
>   GtDocumenter editorForText: BrToggleExamples comment. 
> 
> 
> Tutorials:
> 
> Documenter offers a new experience of writing tutorials for Pharo by enabling 
> the creation and embedding of Epicea change sessions directly in the 
> document. For example, take a look at the following animation:
> https://twitter.com/feenkcom/status/75333972541440
> 
> The document shows a method on top, and a change preview at the bottom 
> showing both the code and the associated diff to the state from the image. 
> Applying the change updates both the change view (no more diff), and method 
> preview. This speeds up significantly the process of going through a 
> tutorial. Furthermore, given that now the document shows the diff to the 
> current image, the reader can safely explore alternative scenario and come 
> back to the tutorial at any time without losing the overview.
> 
> The size of the preview can also be adjusted live:
> https://twitter.com/feenkcom/status/1001152789874167808
> https://twitter.com/feenkcom/status/1001407762285375490
> 
> You can see a live tutorial by inspecting:
>   IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 
> 'doc' / 'tutorial' / 'examples-tutorial.pillar’.
> 
> 
> Interactive data notebook:
> 
> A Documenter document can also be used as an interactive notebook. Internally 
> it essentially acts as a playground:
>   • it supports defining variables in code snippets, and
>   • the execution of code shows an embedded inspector.
> 
> For example:
> https://twitter.com/feenkcom/status/996310432225820672
> https://twitter.com/feenkcom/status/1002851190475026432
> 
> An example, can be seen by inspecting:
>   IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 
> 'gtoolkit' / 'gtoolkit.pillar'. 
> 
> 
> As always, please do let us know what you think.
> 
> Enjoy,
> The feenk team
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "If you can't say why something is relevant, 
> it probably isn't."
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant, 
it probably isn't."

Re: [Pharo-users] [ann] gt documenter

[Tudor Girba]

Hi,

If Moz2D is installed, the fonts should work fine.

Can you please try the installation again? And if it does not work, please let 
me know if in 
Settings Browser / Appearance / Bloc / Preferable Sparta renderering 
backend
you see Moz2D or not.


Cheers,
Doru


> On Jun 15, 2018, at 2:31 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi Doru,
> 
> Thanks for the update in Markdown. I will try to bring better Markdown
> support in Pharo by developing my ideas on a Playground for Markdown
> with syntax highlighting, image preview and so on and maybe I can help
> in incorporating them in GT Documenter on Pharo 7.
> 
> I can confirm that fonts didn't work on Manjaro on 64 bits installation
> running Pharo 64b previously, but maybe in Pharo 7 installation will be
> smoother, including font installation via Moz2D integration (nix package
> manager has been a real asset in our workshops in multiple Unix
> environments, including Mac and several Gnu/Linux flavors, so maybe it
> can help with Moz2D engine and fonts integration).
> 
> Cheers,
> 
> Offray
> 
> 
> On 15/06/18 00:56, Tudor Girba wrote:
>> Hi,
>> 
>> I am happy you like it.
>> 
>> Fonts should work with a Pharo 64b installation on Linux, including Manjaro. 
>> Can you confirm that you use a Pharo 64bit and that it does not work? If 
>> yes, can you describe how you are installing Pharo and GToolkit?
>> 
>> Markdown is certainly interesting, but it is not our focus at this point. We 
>> are building on top of Pillar. There are several reasons for it, two of them 
>> being:
>> 1. To build the experience we want to, we need deep control over the markup 
>> language and Pillar provides that in Pharo.
>> 2. Pillar is the de facto documentation markup used in Pharo, and our 
>> primary focus is to support new kinds of development workflows in this 
>> environment, including handling documentation.
>> 
>> GT 2nd generation will indeed not be part of Pharo 7, but will be loadable 
>> in it.
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>>> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna Cárdenas 
>>>  wrote:
>>> 
>>> Cool! I hope to see how this could be integrated in Grafoscopio once 
>>> Documenter is better integrated with Pharo, for example addressing the font 
>>> issues already reported in the mailing list on Manjaro Linux (64 bits) and 
>>> in the thread at [1] and also the Markdown integration possibilities (which 
>>> are never answered).
>>> [1] https://twitter.com/feenkcom/status/996310432225820672
>>> 
>>> I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to 
>>> use it in a more confident day to day fashion.
>>> 
>>> Keep the interesting work.
>>> 
>>> Cheers,
>>> 
>>> Offray
>>> 
>>> On 13/06/18 15:57, Tudor Girba wrote:
>>>> Hi,
>>>> 
>>>> We are happy to announce a new leap of GToolkit Documenter, the tool for 
>>>> manipulating live documents directly in the development environment:
>>>> https://github.com/feenkcom/gtoolkit-documenter
>>>> 
>>>> Documenter is part of the second generation GToolkit project, it is based 
>>>> on Bloc and works with the latest Pillar. It is mainly developed by Juraj 
>>>> Kubelka.
>>>> 
>>>> Attached you can see a preview of how documents look like:
>>>> 
>>>> 
>>>> 
>>>> At its core it offers a live editor for manipulating Pillar documents. The 
>>>> interaction happens seamlessly directly in the text editor, and it can be 
>>>> combined with different types of previews to serve several classes of use 
>>>> cases:
>>>>• code documentation
>>>>• tutorials
>>>>• interactive data notebook
>>>> 
>>>> 
>>>> Code documentation
>>>> 
>>>> Documenter complements the GToolkit Examples engine to redefine code 
>>>> documentation. When practicing example-driven development, examples get 
>>>> written as part of the typical development. Once examples exist, they can 
>>>> be quickly put together in a document to form documentation. For example, 
>>>> the linked picture shows the comment of a class containing a visual 
>>>> explanation:
>>>> https://twitter.com/feenkcom/status/973899862482866176
>>>> 
>>>> You can see a live example of documentation by inspecting the following 
>>

Re: [Pharo-users] [ann] gt documenter

[Tudor Girba]

Hi,

I am happy you like it.

Fonts should work with a Pharo 64b installation on Linux, including Manjaro. 
Can you confirm that you use a Pharo 64bit and that it does not work? If yes, 
can you describe how you are installing Pharo and GToolkit?

Markdown is certainly interesting, but it is not our focus at this point. We 
are building on top of Pillar. There are several reasons for it, two of them 
being:
1. To build the experience we want to, we need deep control over the markup 
language and Pillar provides that in Pharo.
2. Pillar is the de facto documentation markup used in Pharo, and our primary 
focus is to support new kinds of development workflows in this environment, 
including handling documentation.

GT 2nd generation will indeed not be part of Pharo 7, but will be loadable in 
it.

Cheers,
Doru



> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Cool! I hope to see how this could be integrated in Grafoscopio once 
> Documenter is better integrated with Pharo, for example addressing the font 
> issues already reported in the mailing list on Manjaro Linux (64 bits) and in 
> the thread at [1] and also the Markdown integration possibilities (which are 
> never answered).
> [1] https://twitter.com/feenkcom/status/996310432225820672
> 
> I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to 
> use it in a more confident day to day fashion.
> 
> Keep the interesting work.
> 
> Cheers,
> 
> Offray
> 
> On 13/06/18 15:57, Tudor Girba wrote:
>> Hi,
>> 
>> We are happy to announce a new leap of GToolkit Documenter, the tool for 
>> manipulating live documents directly in the development environment:
>> https://github.com/feenkcom/gtoolkit-documenter
>> 
>> Documenter is part of the second generation GToolkit project, it is based on 
>> Bloc and works with the latest Pillar. It is mainly developed by Juraj 
>> Kubelka.
>> 
>> Attached you can see a preview of how documents look like:
>> 
>> 
>> 
>> At its core it offers a live editor for manipulating Pillar documents. The 
>> interaction happens seamlessly directly in the text editor, and it can be 
>> combined with different types of previews to serve several classes of use 
>> cases:
>>  • code documentation
>>  • tutorials
>>  • interactive data notebook
>> 
>> 
>> Code documentation
>> 
>> Documenter complements the GToolkit Examples engine to redefine code 
>> documentation. When practicing example-driven development, examples get 
>> written as part of the typical development. Once examples exist, they can be 
>> quickly put together in a document to form documentation. For example, the 
>> linked picture shows the comment of a class containing a visual explanation:
>> https://twitter.com/feenkcom/status/973899862482866176
>> 
>> You can see a live example of documentation by inspecting the following 
>> snippet:
>>  GtDocumenter editorForText: BrToggleExamples comment. 
>> 
>> 
>> Tutorials:
>> 
>> Documenter offers a new experience of writing tutorials for Pharo by 
>> enabling the creation and embedding of Epicea change sessions directly in 
>> the document. For example, take a look at the following animation:
>> https://twitter.com/feenkcom/status/75333972541440
>> 
>> The document shows a method on top, and a change preview at the bottom 
>> showing both the code and the associated diff to the state from the image. 
>> Applying the change updates both the change view (no more diff), and method 
>> preview. This speeds up significantly the process of going through a 
>> tutorial. Furthermore, given that now the document shows the diff to the 
>> current image, the reader can safely explore alternative scenario and come 
>> back to the tutorial at any time without losing the overview.
>> 
>> The size of the preview can also be adjusted live:
>> https://twitter.com/feenkcom/status/1001152789874167808
>> https://twitter.com/feenkcom/status/1001407762285375490
>> 
>> You can see a live tutorial by inspecting:
>>  IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 
>> 'doc' / 'tutorial' / 'examples-tutorial.pillar’.
>> 
>> 
>> Interactive data notebook:
>> 
>> A Documenter document can also be used as an interactive notebook. 
>> Internally it essentially acts as a playground:
>>  • it supports defining variables in code snippets, and
>>  • the execution of code shows an embedded inspector.
>> 
>> For example:
>> https://twitter.com/feenkcom/status/996310432

[Pharo-users] [ann] gt documenter

[Tudor Girba]

Hi,

We are happy to announce a new leap of GToolkit Documenter, the tool for 
manipulating live documents directly in the development environment:
https://github.com/feenkcom/gtoolkit-documenter

Documenter is part of the second generation GToolkit project, it is based on 
Bloc and works with the latest Pillar. It is mainly developed by Juraj Kubelka.

Attached you can see a preview of how documents look like:



At its core it offers a live editor for manipulating Pillar documents. The 
interaction happens seamlessly directly in the text editor, and it can be 
combined with different types of previews to serve several classes of use cases:
• code documentation
• tutorials
• interactive data notebook


Code documentation

Documenter complements the GToolkit Examples engine to redefine code 
documentation. When practicing example-driven development, examples get written 
as part of the typical development. Once examples exist, they can be quickly 
put together in a document to form documentation. For example, the linked 
picture shows the comment of a class containing a visual explanation:
https://twitter.com/feenkcom/status/973899862482866176

You can see a live example of documentation by inspecting the following snippet:
GtDocumenter editorForText: BrToggleExamples comment. 


Tutorials:

Documenter offers a new experience of writing tutorials for Pharo by enabling 
the creation and embedding of Epicea change sessions directly in the document. 
For example, take a look at the following animation:
https://twitter.com/feenkcom/status/75333972541440

The document shows a method on top, and a change preview at the bottom showing 
both the code and the associated diff to the state from the image. Applying the 
change updates both the change view (no more diff), and method preview. This 
speeds up significantly the process of going through a tutorial. Furthermore, 
given that now the document shows the diff to the current image, the reader can 
safely explore alternative scenario and come back to the tutorial at any time 
without losing the overview.

The size of the preview can also be adjusted live:
https://twitter.com/feenkcom/status/1001152789874167808
https://twitter.com/feenkcom/status/1001407762285375490

You can see a live tutorial by inspecting:
IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 
'doc' / 'tutorial' / 'examples-tutorial.pillar’.


Interactive data notebook:

A Documenter document can also be used as an interactive notebook. Internally 
it essentially acts as a playground:
• it supports defining variables in code snippets, and
• the execution of code shows an embedded inspector.

For example:
https://twitter.com/feenkcom/status/996310432225820672
https://twitter.com/feenkcom/status/1002851190475026432

An example, can be seen by inspecting:
IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 
'gtoolkit' / 'gtoolkit.pillar'. 


As always, please do let us know what you think.

Enjoy,
The feenk team


--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant, 
it probably isn't."

Re: [Pharo-users] [Pharo-dev] Pharo 10th Anniversary

[Tudor Girba]

+1

Happy anniversary! :)

Doru


> On May 30, 2018, at 10:10 AM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> This short post by Stéphane Ducasse is worth sharing:
> 
>  https://pharoweekly.wordpress.com/2018/05/29/pharo-got-10-years/
> 
> Congratulation !
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Every thing should have the right to be different."

[Pharo-users] feenk log

[Tudor Girba]

Hi,

We were a bit silent the last couple of months. Quite a bit happened in the 
meantime, so here is a summary (for more fine grained announcements, you can 
follow us on Twitter):


Bloc


- Scrolling. We finally have a good scrolling support:
https://twitter.com/feenkcom/status/991690465224331264
This might sound like a trivial feature, but it turns out it is not. We had a 
bug that forced us to rethink the support quite deeply in order to be able to 
debug it. To do this, we now can simulate time in Bloc, which is really cool:
https://twitter.com/feenkcom/status/989797367523233797
https://twitter.com/feenkcom/status/988753142299938817
(as a side note, the bug we fought with was the last 

- Pannable element is a combination of a scrollable element with a scalable 
element, and it offers the possibility either to zoom in/out + scroll, or to 
fit screen and resize when the parent resizes.

- PDF, SVG, PNG, JPG export (based on the underlying Moz2D support):
https://twitter.com/feenkcom/status/976580153802358786
https://twitter.com/feenkcom/status/976578060429484032

- Better curve support:
https://twitter.com/feenkcom/status/990967109193781249
https://twitter.com/feenkcom/status/990971530615107584

- Better debugging support for understanding bounds:
https://twitter.com/feenkcom/status/989138457288167424


Brick


- We now have simple list and columned list widgets. The list is both fast and 
scalable and supports rows of variable heights:
https://twitter.com/feenkcom/status/984744251920658432
https://twitter.com/feenkcom/status/984143821192744961

- Basic tab widget:
https://twitter.com/feenkcom/status/974420432240685062

- Looks: a mechanism for specifying element-specific composition and 
interaction.


GT


- Documenter saw some major improvements. Just a reminder, Documenter is the 
tool that enables live programming and previews directly within Pillar 
documents.
We now have a capability similar to notebooks like Jupyter:
https://twitter.com/feenkcom/status/996310432225820672
We use it extensively to document our code. For example, here is a tutorial 
about playing with looks in Bloc:
https://twitter.com/feenkcom/status/973899862482866176
And we can also express whole tutorials based on Epicea:
https://twitter.com/feenkcom/status/75333972541440

- Diagrammer. We now have better editing support for detailed things such as 
arrow head:
https://twitter.com/feenkcom/status/976341449267531776
While Diagrammer is apparently a tool for diagrams, it has a rather generic 
design that can be utilized for all sorts of use cases. For example, one side 
effect is that now all elements can be visually edited:
https://twitter.com/feenkcom/status/982656456968241152

- Mondrian: Using the new pannable element, we can now zoom in/out and scroll, 
and we can also set element to fit screen. We can also drag elements around.

- Inspector: we now have an initial support for multiple views associated with 
an object. The support is similar to the one from the current inspector. 


Have fun,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"

Re: [Pharo-users] Personal Programming onPharo

[Tudor Girba]

Hi,

First, I concur with what Norbert said.

@Trygve: Could you describe what you would need in more details?

Cheers,
Doru


> On May 8, 2018, at 9:57 AM, Norbert Hartl  wrote:
> 
> 
> 
>> Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug :
>> 
>> Norbert,
>> I stand corrected because I have not followed the mainstream languages as 
>> well as I probably should. Thank you for your candid answer, it clearly 
>> outlines what I can and cannot expect from Pharo and any other ST project. 
>> 
> Ok, I didn’t want to sound too harsh but for me there is no benefit in 
> telling something which is not true. And as a member of such community you 
> get sometimes allergic to things that sound negative because that happens far 
> too often. What I said about not upgrading is the thing we suffer from. While 
> you find it that squeak has moved too fast we consider it that it didn’t move 
> enough. That is why a lot of the sub-systems need to be replaced and that 
> causes instability. For me the stability is outstanding if I look what is 
> changed all the time. But that is another perspective. For a user of the 
> platform it is simply annoying. We know that but not moving is not option for 
> us so that’s why I say that frankly. And sadly the only thing that can 
> compensate side-effects due to changes is to put a lot of man power onto it. 
> The programming/software world has not much too say about how change should 
> be done. 
> 
>> I go back to Alan Kay's vision of a Dynabook: A personal computer for 
>> children of all ages. It should contain all its owner's  personaldata, 
>> including  his or her personal programs, as they evolve through the years.  
>> Continuity is a must; the owner shall never loose data. 
>> 
> We are onto it. If you look at the way we can work, model inspect etc. it is 
> still an wonderful tool. And it is getting better every day while breaking 
> things here and there. I can only repeat what I said earlier. The part of 
> your IDE that copes with language details might break the least because that 
> is the most stable part of the pharo system. But all of the UI system will be 
> replaced in a non-compatible way. Morphic is great but it has grown into a 
> hugly monster. And in this century you might not survive having bitmap based 
> graphics. It might still make perfect sense to you. Because there will be 
> some effort put into the ability to load it into pharo at wish. But I would 
> suspect it won’t change much from there. 
> But it cannot stay because to old-fashioned and not changeable. Maybe it is 
> missing in the Dynabook vision that is not likely that children born after 
> 2000 still won’t too use a graphical interface designed in the 70s being 
> unchanged. But I’m not sure if the Dynabook vision was supposed to be 
> realized some day or just a vehicle to complain about everything.
> 
>> Again, thank you for your answers. They have given invaluable contributions 
>> to my thinking.
> 
> I would have liked to say something more encouraging but ….
> 
> Norbert
> 
>> --Trygve.
>> 
>> 
>> On 07.05.2018 14:14, Norbert Hartl wrote:
>>> 
 Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug :
 
 Please tell me when Java, C, C++, etc programs stopped working because 
 their runtime systems had changed.
 Please tell me when Java, C, C++, etc compilers stopped compiling old code 
 because the languages had changed.
 
>>> If we talk about C/C++ the runtime is the operating system. Everytime I 
>>> update it the linked libraries are suspect to be invalid from then. If you 
>>> have in the same system update a new version of the C compiler you are 
>>> doomed. You cannot link your binary with the new libs. And the new C 
>>> compiler quirks about your code. So what you have then? Staying on an old C 
>>> language standard? Statically link everything. Ah no that won’t work 
>>> because you would have to care about all your dependencies being compilable 
>>> with the new compiler. But you don’t update the compiler meaning you don’t 
>>> update the operating system. It is the same as staying on pharo 3.
>>> 
>>> For Java the situation is slightly different because if you use new 
>>> programming language features you can only do when switching the compiler 
>>> to the new standard. There is a lot of effort that went into making the 
>>> java vm recognize the language version and execute regarding that making 
>>> version compatible. We are in sync here. I told you it is about manpower. 
>>> Do you know how much manpower it needed and how long it took to add 
>>> something like closures to the java language? Do you consider java closure 
>>> to be en par with other languages?
>>> 
>>> We are sorry not everything is to your liking. It is not even to our own 
>>> liking because we have dreams far beyond. But we will never get there if we 
>>> don’t take the effort. And the point of open source (did I 

Re: [Pharo-users] #ast vs. #parseTree

[Tudor Girba]

How about: #newAst & #cachedAst?

Cheers,
Doru


> On May 3, 2018, at 9:30 AM, Guillermo Polito  
> wrote:
> 
> method newAst ?
> 
> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras 
>  wrote:
> a "parse tree" is not equal to an "ast"(abstract syntax tree)
> but its difficult to find a name for an ast that is not cached.
> maybe 
> parsedAst
> parseAst
> 
> 
> 
> On Wed, May 2, 2018 at 3:28 PM, Richard Sargent 
>  wrote:
> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov  
> wrote:
> Hi.
> 
> Maybe #parseSourceCode would be better name for #parseTree. 
> 
> I've always found it good advice to avoid using a verb phrase to name 
> something which does not entail some kind of action.
> #parseSourceCode realy reads like something which would parse the source 
> code. #parseTree also has that effect, except for the lack of a tree to parse.
> 
>  
> 
> 2018-05-02 16:33 GMT+03:00 Marcus Denker :
> 
> 
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris  wrote:
> > 
> > Marcus Denker-4 wrote
> >> I will add comments…
> > 
> > I got confused by this again and created an issue:
> > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
> > 
> > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> > add the comments, but not sure I understand the issue well enough. IIUC #ast
> > is cached, but #parseTree is not. What I don't understand is the purpose of
> > this difference and when one would use one over the other.
> 
> the cached #ast is for one interesting for speed (that is, in situations 
> where you ask for it often).
> 
> The other use-case is if you want to annotate the AST and keep that 
> annotation around (till the next
> image save, but you can subscribe to ASTCacheReset and re-install the AST in 
> the cache after cleaning.
> (This is used by MetaLinks to make sure they survive image restart).
> 
> The last thing that it provides is that we do have a quite powerful mapping 
> between bytecode/text/context
> and the AST. Regardless how you navigate, you get the same object.
> 
> e.g. even this one works:
> 
> [ 1+2 ] sourceNode == thisContext method ast blockNodes first
> 
> > For example,
> > when, if ever, would a user want to access a CM's #ast (as opposed to
> > #parseTree) and could modifying it create problems?
> > 
> 
> Modification is a problem, yes.. code that wants to modify the AST without 
> making sure the compiledMethod is in sync later
> should use #parseTree. 
> 
> Code that does not modify the AST (or makes sure to compile it after 
> modification) is free to use #ast. 
> or if you want to annotate the AST (which is a modification, after all).
> 
> This is not perfect (not at all…) but the simplest solution to get (to some 
> extend) what you would have if the system would have
> a real persistent, first class AST…
> 
> To be improved. The ASTCache with it’s naive “lets just cache everything till 
> the next image save” was done with the idea to see
> when it would show that it is too naive… for that it worked amazingly well 
> till now.
> 
> Marcus
> 
> 
> 
> 
> 
> -- 
> Bernardo E.C.
> 
> Sent from a cheap desktop computer in South America.
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"

Re: [Pharo-users] Showcasing Pharo, Roassal and Grafoscopio at re:publica 2018

[Tudor Girba]

Excellent!

Doru


> On Apr 26, 2018, at 3:57 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> I will be showcasing Pharo, Roassal and Grafoscopio at re:publica 2018,
> next week. As you may know, re:publica[2] is one of the most important
> and visible media & digital culture conventions in Europe and is a good
> scenario for the Pharo community.  You can find details about my
> participation at [1]
> 
> [1]
> https://18.re-publica.com/en/session/data-clinic-twitter-data-selfies-data-portraits
> [2] https://18.re-publica.com/en
> 
> I will be making intensive refactoring on the Dataviz package to create
> some usual and unusual data visualizations from data exported from
> Twitter, so I may be more active those days in the Discord and mailing
> list channels, is some questions arise.
> 
> Thanks in advance for the Pharo communities support. I wouldn't be able
> to be there without it.
> 
> Cheers,
> 
> Offray
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] [ANN] Agile Artificial Intelligence: Programming Neural Networks in Pharo

[Tudor Girba]

Nice :)

Doru


> On Apr 18, 2018, at 2:53 PM, Alexandre Bergel  wrote:
> 
> Hi!
> 
> It is now time to share an early version of a new book. 
> https://agileartificialintelligence.github.io
> 
> Feedback is very welcome.
> 
> Kind regards,
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."

Re: [Pharo-users] Playground and Smalltalk script

[Tudor Girba]

Hi,

It would if we would be able to know that there is no search possible within a 
context.

In your case, an .st file is a FileReference, and this class defines several 
searches (for example for files in a folder). Thus we cannot guarantee 
statically that no search is possible, so we chose to allow you to always dive 
in.

But, this is the behavior of the generic Spotter. In your case you want a more 
restricted behavior (simple list, no dive in), and this is certainly 
legitimate, and it would be ideal to support it.

Cheers,
Doru

> On Apr 17, 2018, at 8:53 PM, Hilaire <hila...@drgeo.eu> wrote:
> 
> Ok, got it.
> 
> And what about no dive-in if there is no search in that context. Will it be 
> consistent with the overall behavior of Spotter?
> 
> 
> Le 17/04/2018 à 19:37, Tudor Girba a écrit :
>> In your case, if you dive in an .st file, the Spotter will try to search 
>> within that context. As there is no search, it will show an empty pane. It 
>> is not ideal, but at the time we did not find a better solution.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-users] Playground and Smalltalk script

[Tudor Girba]

At every step, Spotter shows you the searches defined for the object you are 
looking at. The very first object is an instance of GTSpotter itself. If you 
dive in an object, the search will be performed within the context of that 
object.

In your case, if you dive in an .st file, the Spotter will try to search within 
that context. As there is no search, it will show an empty pane. It is not 
ideal, but at the time we did not find a better solution.

Doru

> On Apr 17, 2018, at 5:34 PM, Hilaire <hila...@drgeo.eu> wrote:
> 
> Okay, activate the preview by default, nicer, not sure if it should be 
> activated after all.
> 
> The Ctrl-Right dives in still produces empty frame. Is it because dive-in has 
> no operation on .st scripts?
> 
> Thanks
> 
> Hilaire
> 
> 
> Le 17/04/2018 à 11:34, Tudor Girba a écrit :
>> Indeed, the preview is deactivated by default. Please use Ctrl+P for 
>> toggling preview. Ctrl+Right dives in the object.
>> 
>> If you want to script it, take a look at:
>> GTSpotter class>>#exampleWithPreview
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Obvious things are difficult to teach."

Re: [Pharo-users] Playground and Smalltalk script

[Tudor Girba]

Hi,

I did try out.

Indeed, the preview is deactivated by default. Please use Ctrl+P for toggling 
preview. Ctrl+Right dives in the object.

If you want to script it, take a look at:
GTSpotter class>>#exampleWithPreview

Cheers,
Doru

> On Apr 17, 2018, at 10:49 AM, HilaireFernandes  wrote:
> 
> Of course I meant Ctrl-Right, the preview on .st. script is then empty.
> Or do I have the preview unactivated?
> 
> Try out the built I proivde a link to, it now works on Mac OSX too :)
> 
> Thanks
> 
> 
> Hilaire
> 
> 
> 
> -
> http://drgeo.eu
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

--
www.tudorgirba.com
www.feenk.com

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] Playground and Smalltalk script

[Tudor Girba]

Hi,

The preview happens with Ctrl+p (or clicking on the large gray arrow that goes 
out of the window frame).

Ctrl+Right goes inside the selected object and tries to search there.

Cheers,
Doru

> On Apr 16, 2018, at 9:34 PM, Hilaire  wrote:
> 
> The issue can be seen in the built at 
> https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0
> 
> In the world menu, just select "Open script", Spotter is open in a folder 
> full of .st scripts, Ctrl-Left does not preview the script content, any idea?
> 
> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] QRCode - A thank you note

[Tudor Girba]

Hi Sven,

Thanks a lot for the positive message!

Indeed, it is a much needed perspective, and I am sure there are many other 
similar examples.

Btw, nice work, too :).

Cheers,
Doru



> On Apr 13, 2018, at 8:47 PM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> Given that the mailing lists are often used to ask questions when we get in 
> trouble, report bugs and other issues, conduct public discussion between 
> strong headed individuals, we quickly forget what a fantastic platform Pharo 
> is.
> 
> Last month I implemented a rough MVP-style ticket sales platform that was 
> successfully used to sell and validate at the entrance, about 1000 digital, 
> online tickets for a relatively large 3000+ attendance event (a party). It 
> took only a couple of days to build and deploy, and it was a lot of fun - it 
> was even done in 'unstable' Pharo 7.
> 
> Early on I decided to identify each individual ticket by a unique URL. For 
> easier presentation and scanning purposes, I encoded that URL in a QR code.
> 
> Although I am grateful for the whole Pharo ecosystem (including Seaside), we 
> all build on top of other people's work, I was especially happy with Jochen 
> Rick's QRCode package (http://smalltalkhub.com/#!/~JochenRick/QRCode/). This 
> is such a great piece of work !
> 
> It worked right out of the box in Pharo 7 (even though it is from 2013/2014), 
> was well designed, easy to figure out, was well documented, had unit tests. I 
> can't say anything bad about it, it is as close to perfect as I have ever 
> seen. So: thanks Jochen, you made my day !
> 
> Here is how a ticket generates its own QR code:
> 
> T123Ticket>>#asQRCode
>   ^ self url asString asQRCode formWithQuietZone magnifyBy: 5
> 
> Just beautiful.
> 
> It is also easy (for a non-graphics, non-UI person like me) to combine the QR 
> code with some text:
> 
> T123Ticket >>#asQRCodeWithText
>   | form font |
>   form := Form extent: 535 @ 185 depth: 1.
>   font := LogicalFont familyName: 'Bitmap DejaVu Sans' pointSize: 14.
>   self asQRCode displayOn: form at: 0 @ 0.
>   form getCanvas
> drawString: self url asString at: 180 @ 20 font: font color: Color black;
> drawString: self id36, ' - ', ticketId asString at: 180 @ 45 font: font 
> color: Color black;
> drawString: (name ifNil: [ 'N.N' ]) at: 180 @ 90  font: font color: Color 
> black;
> drawString: (email ifNil: [ '@' ]) at: 180 @ 115 font: font color: Color 
> black;
> drawString: (phone ifNil: [ '+' ]) at: 180 @ 140 font: font color: Color 
> black.
>   ^ form
> 
> Next we combine this with a nice template designed by a graphics artist:
> 
> T123Ticket >>#asQRCodeWithTextInTemplate
>   | templateFile form |
>   templateFile := 'tickets123-template-{1}.jpg' format: { self event id }.
>   form := PluginBasedJPEGReadWriter formFromFileNamed: templateFile.
>   self asQRCodeWithText displayOn: form at: 20@540.
>   ^ form
> 
> And finally, the ticket form is encoded as a JPEG (to be mailed and so on):
> 
> T123Ticket >>#asJPEGBytes
>   ^ ByteArray streamContents: [ :out | 
>   PluginBasedJPEGReadWriter putForm: self asQRCodeWithTextInTemplate 
> onStream: out ]
> 
> 
> 
> I also found GT Inspector very handy (again) in doing back end work (managing 
> payments and other administration), especially the ability to use Spotter on 
> a collection open in an inspector.
> 
> Anyway, I know many of you have similar happy experiences, I just wanted to 
> share (one of) mine.
> 
> Thanks Jochen, thanks everyone.
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Speaking louder won't make the point worthier."

Re: [Pharo-users] [Moose-dev] Re: [ann] gt diagrammer

[Tudor Girba]

Hi,


> On Apr 8, 2018, at 10:27 AM, Hernán Morales Durand <hernan.mora...@gmail.com> 
> wrote:
> 
> Hi Tudor,
> 
> Very nice! Thank you for sharing, this seems to be hard work.

Thanks.

> If you welcome some feedback:
> 
> Live tab:
> - When I select "Figure" button, then choose from the figures toolbar and put 
> a figure, the selection focus goes back to the "Select" button loosing the 
> figures toolbar. It would be nice to save some clicks by staying in the 
> Figure when putting a lot of figures.

Indeed, we are thinking about keeping the Figure mode when pressing Shift.

> - The "Figure" are actually UML figures? It would be cool to categorize the 
> types of figures available in a toolbar.

The Figures is actually any figures. The figures available are there for 
validation to show that both simple figures and complicated one (such as a UML 
class) can work fine. But, you can define your own stencils (factories of 
figures) and they will appear there.

> - Clicking "Line" button does not display any lines to select (maybe ToDo?)

ToDo indeed :).

> Events tab
> - I guess is used for Undo/Redo
> "User data", "Resizers", and "Transformation"
> - I didn't understood what are they for.

These are element specific views in the inspector, each interesting for 
different purposes. For example, the Events presentation shows a log of all 
events that reached the element - a very useful input when debugging UI logic.

> I am intrigued by the "inject visual attributes" per-instance, maybe 
> something like the old Parts Workbench from VisualSmalltalk?

I do not know what the Parts Workbench is. In our case, we want to be able to 
specify the look of an element independent from the element itself, and we want 
to be able to do that per element instance, not per type, and not as a global 
behavior (like in the current theme).

Cheers,
Doru

> Cheers,
> 
> Hernán
> 
> 
> 
> 
> 2018-04-07 13:39 GMT-03:00 Tudor Girba <tu...@tudorgirba.com>:
> Hi,
>  
> We are happy to announce an initial version of GT Diagrammer, an engine for 
> constructing diagrams interactively. This is the newest addition to the next 
> generation GT built on Bloc.
>  
> It looks like this:
> https://twitter.com/feenkcom/status/976341449267531776
> 
> 
>  
> We chose to work on Diagrammer for multiple reasons. First, developers often 
> need to create hand built diagrams to communicate intentions, and an 
> integrated experience should not require us to leave our environment to 
> create them. At the same time, Diagrammer is an application that requires a 
> widgets and interactions, and thus it is a nice exercise for Bloc and Brick.
> 
> One requirement we had from the beginning was to make it work with any Bloc 
> element. This means that the editing part had to be reasonably generic. To 
> this end, we now have elements that can define visual editors. This is 
> somewhat a combination between Magritte descriptions, and inspector 
> extensions. An interesting side effect is that now we can edit visual 
> properties when inspecting any element. In other words, we got the basic 
> infrastructure of a UI painter. It looks like this:
> https://twitter.com/feenkcom/status/982656456968241152
>  
> The user interface essentially relies on two widgets: scrollable list and 
> toggle button. While the visual look of the toggle button is inspired from 
> material design, the most interesting part is that now we have an 
> implementation for controlling looks per element instance. A key issue here 
> is that looks can react to events coming from the element and inject visual 
> attributes and possible even change behavior (for example, changing an icon 
> while pressing a button). We will post more about looks soon.
>  
> We now also have a nice solution for overlays. For example, we have an 
> overlay showing selection and an overlay for resizing elements.
>  
> Perhaps less obvious, Diagrammer also offers a basic infrastructure for the 
> area of visual languages. As Diagrammer works with any Bloc elements, we can 
> simply create dedicated visual elements. As an example, Diagrammer comes with 
> an implementation of a UML class figure. Furthermore, as the functionality 
> does not impose a specific model, custom language semantics can be mapped on 
> visual actions.
>  
> There are several things to do still for it to become a mature solution. An 
> important next step is to serialize a diagram scene in a reproducible manner. 
> Currently, the diagram (or any element) can be exported as pdf 
> (https://twitter.com/feenkcom/status/976580153802358786), svg 
> (https://twitter.com/feenkcom/status/976578060429484032), pn

[Pharo-users] [ann] gt diagrammer

[Tudor Girba]

Hi,
 
We are happy to announce an initial version of GT Diagrammer, an engine for 
constructing diagrams interactively. This is the newest addition to the next 
generation GT built on Bloc.
 
It looks like this:
https://twitter.com/feenkcom/status/976341449267531776


 
We chose to work on Diagrammer for multiple reasons. First, developers often 
need to create hand built diagrams to communicate intentions, and an integrated 
experience should not require us to leave our environment to create them. At 
the same time, Diagrammer is an application that requires a widgets and 
interactions, and thus it is a nice exercise for Bloc and Brick.

One requirement we had from the beginning was to make it work with any Bloc 
element. This means that the editing part had to be reasonably generic. To this 
end, we now have elements that can define visual editors. This is somewhat a 
combination between Magritte descriptions, and inspector extensions. An 
interesting side effect is that now we can edit visual properties when 
inspecting any element. In other words, we got the basic infrastructure of a UI 
painter. It looks like this:
https://twitter.com/feenkcom/status/982656456968241152
 
The user interface essentially relies on two widgets: scrollable list and 
toggle button. While the visual look of the toggle button is inspired from 
material design, the most interesting part is that now we have an 
implementation for controlling looks per element instance. A key issue here is 
that looks can react to events coming from the element and inject visual 
attributes and possible even change behavior (for example, changing an icon 
while pressing a button). We will post more about looks soon.
 
We now also have a nice solution for overlays. For example, we have an overlay 
showing selection and an overlay for resizing elements.
 
Perhaps less obvious, Diagrammer also offers a basic infrastructure for the 
area of visual languages. As Diagrammer works with any Bloc elements, we can 
simply create dedicated visual elements. As an example, Diagrammer comes with 
an implementation of a UML class figure. Furthermore, as the functionality does 
not impose a specific model, custom language semantics can be mapped on visual 
actions.
 
There are several things to do still for it to become a mature solution. An 
important next step is to serialize a diagram scene in a reproducible manner. 
Currently, the diagram (or any element) can be exported as pdf 
(https://twitter.com/feenkcom/status/976580153802358786), svg 
(https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by 
directly using the low level canvas. However, for the diagram to be truly 
useful we need to store the result in either code or another reloadable form 
such as STON. Other future directions are related to figure controlling (for 
example, custom anchors or line bending points) and to enhanced editors.
 
To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Metacello new
   baseline: 'GToolkit';
   repository: 'github://feenkcom/gtoolkit/src';
   load.
 
And then inspect:
GtDiagrammerElement new
 
Cheers,
The feenk team
 

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-users] [Pharo-dev] PharoDays: 14/15 June 2018

[Tudor Girba]

Hi,

Unfortunately, those dates do not work well for me. it would be hard for me to 
get there on those days.

Cheers,
Doru


> On Mar 23, 2018, at 11:21 AM, Stephane Ducasse  
> wrote:
> 
> Hi All
> 
> We would like to organise PharoDays the 14 and 15 June. Could you tell us
> if you see big problems from your side before we announce it.
> 
> Tx
> 

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

Re: [Pharo-users] Disabling GTSpotter dive in

[Tudor Girba]

That can be an option.

Doru


> On Mar 19, 2018, at 9:52 AM, Peter Uhnák <i.uh...@gmail.com> wrote:
> 
> So I imagine something like the following
> 
> spotterFieldsFor: aStep
>   
>   ^ aStep listProcessor
>   title: 'Fields';
>   canDiveIn: [ false "or some dynamic condition" ];
>   ...
> 
> On Mon, Mar 19, 2018 at 9:05 AM, Peter Uhnák <i.uh...@gmail.com> wrote:
> Certainly.
> 
> Basically I want to avoid a situation, where diving in would result in an 
> empty spotter:
> 
> 
> 
> 
> 
> 
> So instead I would like to remove the dive in capability (both the icon, and 
> the action), when the result will be empty. (And of course keep it if there 
> will be something).
> 
> Ideally it should be possible to define it in the "parent" step, because 
> sometimes I know there will be no further steps, and sometimes the result is 
> simply empty (in which case I might still want to show that there are zero 
> children).
> 
> Thanks,
> Peter
> 
> On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
> Hi,
> 
> I am not sure I understand the issue. Can you re-explain it please?
> 
> Cheers,
> Doru
> 
> 
> > On Mar 16, 2018, at 8:02 AM, Peter Uhnák <i.uh...@gmail.com> wrote:
> >
> > correction:  spotterForRenderingShapesFor: is not in Pharo 6.1 (it's added 
> > by Roassal2GT)
> >
> > On Fri, Mar 16, 2018 at 8:01 AM, Peter Uhnák <i.uh...@gmail.com> wrote:
> > Hi,
> >
> > is it possible to disable GTSpotter dive in functionality when the result 
> > would be empty?
> >
> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no matter 
> > what there will be at least one processor (at least the "parent" one, which 
> > is weird).
> >
> > Also there are two spotter extensions directly on Object (Pharo 6.1)
> > * spotterForRenderingShapesFor:
> > * spotterRePropertiesFor:
> >
> > which are always applied... but canDiveIn: was returing true even when I 
> > disabled them.
> >
> > Thanks,
> > Peter
> >
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Obvious things are difficult to teach."
> 
> 
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the 
software gets."

Re: [Pharo-users] Disabling GTSpotter dive in

[Tudor Girba]

Hi,

I am not sure I understand the issue. Can you re-explain it please?

Cheers,
Doru


> On Mar 16, 2018, at 8:02 AM, Peter Uhnák  wrote:
> 
> correction:  spotterForRenderingShapesFor: is not in Pharo 6.1 (it's added by 
> Roassal2GT)
> 
> On Fri, Mar 16, 2018 at 8:01 AM, Peter Uhnák  wrote:
> Hi,
> 
> is it possible to disable GTSpotter dive in functionality when the result 
> would be empty?
> 
> I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no matter 
> what there will be at least one processor (at least the "parent" one, which 
> is weird).
> 
> Also there are two spotter extensions directly on Object (Pharo 6.1)
> * spotterForRenderingShapesFor:
> * spotterRePropertiesFor:
> 
> which are always applied... but canDiveIn: was returing true even when I 
> disabled them.
> 
> Thanks,
> Peter
> 

--
www.tudorgirba.com
www.feenk.com

"Obvious things are difficult to teach."

Re: [Pharo-users] confusion about GTFilter hierarchy and GTFilterSubstring

[Tudor Girba]

Hi,

I am not sure I understand the confusion.

The filter is a strategy used to select objects. GTFilterSubstring filters 
based on finding the input string as a substring in the string representation 
of the objects. You do not see a difference because by default, the logic is a 
substring matching one.

Cheers,
Doru

> On Mar 16, 2018, at 7:29 AM, Peter Uhnák  wrote:
> 
> Hi,
> 
> what exactly is GTFilterSubstring for?
> The observed behavior is identical whether I use it in my spotter method or 
> not. (As I don't know what exactly it does it's hard to observe it in the 
> first place...)
> Also as none of the concrete classes in the GTFilter hierarchy have comments 
> it's hard to guess what is their respective difference/value.
> 
> Thanks,
> Peter

--
www.tudorgirba.com
www.feenk.com

"Next time you see your life passing by, say 'hi' and get to know her."

Re: [Pharo-users] Ever growing image

[Tudor Girba]

Thanks!

Doru


> On Mar 13, 2018, at 8:24 PM, Guillermo Polito  
> wrote:
> 
> I'll take a look at this from tomorrow morning till the end of the week.
> 
> On Tue, Mar 13, 2018 at 7:22 PM, Stephane Ducasse  
> wrote:
> Hilaire
> 
> I do not have the answer and I do not know but you should have a look
> at the bash script.
> Because this is where the logic is. I will discuss tomorrow with
> guille (right now I'm sick).
> Stef
> 
> On Mon, Mar 12, 2018 at 9:34 PM, Hilaire  wrote:
> > Le 12/03/2018 à 10:16, Guillermo Polito a écrit :
> >>
> >> That said, I would also like to have a smaller and more malleable system,
> >> in that I agree with you, but that takes time and work, and I see few 
> >> people
> >> that is diving in the insides of Pharo to help get us something in that
> >> direction. Not because they don't care but because it is difficult and time
> >> consuming.
> >
> >
> > Which direction should I follow after building a boostrap image following
> > these instructions
> > https://github.com/pharo-project/pharo#bootstrapping-pharo-from-sources ?
> >
> >
> > --
> > Dr. Geo
> > http://drgeo.eu
> >
> >
> >
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."

Re: [Pharo-users] Help Petit Parse

[Tudor Girba]

That is indeed the solution.

Doru


> On Mar 13, 2018, at 6:16 AM, Holger Freyther  wrote:
> 
> 
> 
>> On 12. Mar 2018, at 23:07, Pau Guillot  wrote:
>> 
>> (#word asParser , #digit asParser plus flatten ==> [:node | node second])
>> star parse: 'A123A123'. 
>> -> #('123' '123')
> 
> (((#word asParser , #digit asParser plus flatten ==> [:node | node second]) 
> plus) ==> [ :node  | '' join: node]) parse: 'a123a123'
> => '123123'
> 
> probably there is a nicer way. ;)

--
www.tudorgirba.com
www.feenk.com 

“Live like you mean it."

Re: [Pharo-users] Something is happening...

[Tudor Girba]

This might be how super linear growth feels like once you pass the bending 
point.

Doru


> On Mar 13, 2018, at 8:27 AM, Marcus Denker  wrote:
> 
> Hi,
> 
> There is something odd happening… or better: There is *a lot* happening. 
> 
> Just one example: for the Newsletter, the original idea was to send out once 
> a month a post with 3 things, some of them recycled (e.g. pointers to 
> existing projects, re-use “success stories”, things like that.
> 
> Now already some months ago I had to add “and here are some other interesting 
> announcements, blog posts, videos”. 
> 
> But this month, the list of things for the newsletter TODO list contains over 
> 60 entries. With the exception of maybe 5, these are just things that 
> happened between sending the February newsletter and today.
> 
> Newsletter March should be ready till this thursday, I hope, subscribe or 
> read the oder ones here: http://newsletter.pharo.org
> 
>   Marcus

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."

[Pharo-users] feenk log

[Tudor Girba]

Hi,

Here is an update of the work on Bloc, Brick and GT. As always, please do let 
us know what you think.

Bloc:
- Improved the deletion in the text editor and covered the scenarios with 
examples
- Worked on the text selection. Still work needed for selection to be 
production ready:
https://twitter.com/feenkcom/status/969183393547259905
- Balanced rope structure for even better performance of the editor. Overall, 
the performance of the text editor improved 2x.
https://twitter.com/feenkcom/status/971009488789516288
- Selectable curves:
https://twitter.com/feenkcom/status/967690664589910016

Brick:
- Resizer overlay. The tweet below also shows how we can now easily script 
dragging behavior in examples:
https://twitter.com/feenkcom/status/971990195011690496

GToolkit:
- Diagrammer is a new engine for drawing diagrams based on Bloc. This is the 
first version, and we will continue working on it in the following weeks, so 
stay tuned for more news. This is also one of the first Bloc applications:
https://twitter.com/feenkcom/status/972243179599794180
- Andrei put together a beautiful description of a scenario in which an 
application is molded interactively in the Playground & Inspector. The subject 
is face recognition, and the resulting code is both functional and explainable. 
This is intended as a tutorial material that shows what moldable development 
means and how it changes the way we program:
https://twitter.com/feenkcom/status/972907051448979458

Have fun,
The feenk team
www.feenk.com









--
www.tudorgirba.com
www.feenk.com

"To utilize feedback, you first have to acquire it."

Re: [Pharo-users] [ANN] Cruiser: A Pharo app packager

[Tudor Girba]

Very cool. Thanks!

Doru


> On Mar 8, 2018, at 8:29 PM,  
>  wrote:
> 
> Hi Pharoers!
>  
> I pleased to announce you the first release of Cruiser: a tool to package 
> your Pharo applications. The idea is to quickly convert an application from a 
> development environment to a production one. A production environment means:
>   • No writing on the disk
>   • No access to the source code (by the shortcuts, debugger,...)
>   • No error displaying on the interface
>   • The only thing accessible is the user application
>  
> I let you discover it on: https://github.com/VincentBlondeau/Cruiser
>  
> 
>  
> Do not hesitate to ask me questions or contribute to improve it!
>  
> Cheers,
>  
> Vincent Blondeau 
> Software Engineer, Software and Controls | Global Product Group 
> Desk +1 510.572.7499
> 
> Lam Research Corporation
> 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com
> Connect with Lam Research: Facebook | Twitter | LinkedIn
> 
>  
> NOTICE: This e-mail transmission may contain confidential information. If you 
> are not the intended recipient, or a person responsible for delivering it to 
> the intended recipient, you are hereby notified that any disclosure, copying, 
> distribution or use of any of the information contained in or attached to 
> this message is STRICTLY PROHIBITED. If you have received this transmission 
> in error, please immediately notify the sender and destroy the original 
> transmission and its attachments without reading them or saving them to disk. 
> Thank you.

--
www.tudorgirba.com
www.feenk.com

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."

Re: [Pharo-users] [Pharo-dev] [Issue Tracker] lots of "auto close" happening

[Tudor Girba]

Thanks a lot for this!

Doru


> On Mar 2, 2018, at 7:01 PM, Marcus Denker  wrote:
> 
> Hello,
> 
> As you might now, we automatically close issue tracker entries after 1 year 
> of in-activity.
> Due to two factors (the job doing it not working since 1 month *and* now 
> being 1 year
> after we started to sort issues for “has to be fixed for pharo6 yes or no”, 
> we enter
> a period where *a lot* of issue get auto-closed.
> 
> Everyone subscribed to the issue gets a mail and (of course!!) you should 
> re-opne the
> issue tracker entry if the case still is relevant.
> 
>   Marcus

--
www.tudorgirba.com
www.feenk.com

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."

Re: [Pharo-users] adding 1 year to the date - bug?

[Tudor Girba]

+1

Doru


> On Feb 26, 2018, at 10:54 AM, Norbert Hartl  wrote:
> 
> Forgot to say that this is something you can experience quite often. To me 
> the problem is that 1 year gives a duration immediately. It should work as 
> all units that 1 year is a unit of magnitude 1 and unit year. If you apply 
> this to a date you could make it properly to give the date one year later. 
> I noticed that problem when I started to use the Units package of Marcus. It 
> works for all units except durations because these are already taken. So for 
> me there would be two benefits changing that. 
> 
> Norbert
> 
> 
>> Am 26.02.2018 um 10:48 schrieb Norbert Hartl :
>> 
>> 
>> 
>>> Am 26.02.2018 um 10:43 schrieb Petr Fischer :
>>> 
>>> Hello, just simple test:
>>> 
>>> (Date year: 2019 month: 2 day: 26) + 1 year.
>>> returns: 26 February 2020
>>> OK
>>> 
>>> (Date year: 2020 month: 2 day: 26) + 1 year.
>>> returns: 25 February 2021
>>> What?
>>> 
>>> (maybe I do not understand something  about dates again)
>> 
>> That is a conceptual problem. 1 year is a duration. As it does not know 
>> which year it is the normal 365 days. And 2020 is a leap year so has 366 
>> days. That’s why the date is shifted.
>> 
>> Norbert
> 

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-users] Pharo and Moose lectures in Serbia

[Tudor Girba]

Excellent!

Doru

> On Feb 18, 2018, at 9:26 PM, Stephane Ducasse  wrote:
> 
> Hi
> 
> just a little mail to announce that next week I will give some
> lectures at the University of Novi sad on Pharo and Moose.
> I hope that we will have some serbian pharoers soon.
> 
> Stef
> 

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."

Re: [Pharo-users] GT Documenter status

[Tudor Girba]

Hi,

Thanks for the report. Unfortunately, I do not see the screenshot. Can you 
resend it?

If you installed the code using your script, you should gotten Moz2D as well.

Doru


> On Feb 8, 2018, at 7:59 PM, Peter H. Meadows via Pharo-users 
>  wrote:
> 
> 
> From: "Peter H. Meadows" 
> Subject: GT Documenter status
> Date: February 8, 2018 at 7:59:26 PM GMT+1
> To: Any question about pharo is welcome 
> 
> 
> Hi. I'm looking at GT Documenter in Pharo 6.1 on Ubuntu.
> It doesn't display any spaces, and some of the text looks strange.
> (see attachment for screenshot).
> Why?
> (screenshot is from Moose6.1 beta image, but it's the same in Pharo6.1)
> 
> The screenshot from https://github.com/feenkcom/gtoolkit looks normal.
> 
> It's using Cairo? Is the plan still to switch to Moz2D?
> 
> I installed by:
> Metacello new
>   baseline: 'GToolkit';
>   repository: 'github://feenkcom/gtoolkit/src';
>   load.
> 
> Image
> -
> /home/phm/Pharo/images/Moose Suite 6.1 (beta)/Moose Suite 6.1 (beta).image
> Pharo6.0
> Latest update: #60529
> Unnamed
> 
> Virtual Machine
> ---
> /home/phm/Pharo/vms/61-x86/lib/pharo/5.0-201707201942/pharo
> CoInterpreter VMMaker.oscog-eem.2254 uuid:
> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> 
> Unix built on Jul 20 2017 20:49:20 Compiler: 4.6.3
> VMMaker versionString VM: 201707201942
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul
> 20 12:42:21 2017 -0700 $ Plugins: 201707201942
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> CoInterpreter VMMaker.oscog-eem.2254 uuid:
> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
> 
> Operating System/Hardware
> -
> unix linux-gnu i686
> 
> Thanks in advance.
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."

Re: [Pharo-users] [Moose-dev] feenk log

[Tudor Girba]

Hi,

> On Jan 21, 2018, at 10:37 PM, Ben Coman <b...@openinworld.com> wrote:
> 
> On 21 January 2018 at 23:55, Tudor Girba <tu...@tudorgirba.com> wrote:
>> Hi,
>> 
>> There is a difference in performance. The Announcement is slower (about 2-3x 
>> slower). However, for 1M events the difference is measured in a 200-400ms, 
>> which is very small.
> 
> So you mean each event <1ms difference?
> btw, what is the biggest usage of events? I guess mouse movements?
> How many such events typically in 1 second of movement?
> How is performance on StackInterpreter VM?
> I guess we should keep that performant for platforms lacking JIT like
> iPads, etc…

It depends on the scene. We are still looking into how to evaluate this. That’s 
why we still have both implementations around.


>> The benefit of using Announcement is that we can reuse the tooling around 
>> Announcement, such as blogging and debugging.
> 
> This looks really useful.  Can you describe the difference between the
> red and blue lines in the picture of the first link?

Each event goes through two passes, like in JavaScript:
- The first is called “capturing” (or filtering) and goes from the root to the 
leaf. This is to allow a parent to prevent a child to react to an event.
- The second one is called “bubbling” (or handling) and goes from the leaf to 
the root. This is to find the most specific element to handle the event.

Cheers,
Tudor


> cheers -ben
> 
>> 
>> Still, the way it is used in Bloc is different from the typical usage in 
>> that Bloc registers to all Events (which are Announcements) and then 
>> dispatches through them to specific Element method (like 
>> BlEventListener>>clickEvent:). Still the cool thing is that you also can 
>> still register from the outside to a specific event using a normal when:do:.
>> 
>> We will write a piece of doc about it.
>> 
>> Cheers,
>> Tudor
>> 
>> 
>>> On Jan 21, 2018, at 4:46 PM, Stéphane Ducasse <stephane.duca...@inria.fr> 
>>> wrote:
>>> 
>>> this looks really cool.
>>> For the event I remember the discussion with glenn about the difference and 
>>> I forgot.
>>> 
>>> Stef
>>> 
>>>> On 21 Jan 2018, at 15:54, Tudor Girba <tu...@tudorgirba.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Here is an update of the work on Bloc and GT. As always, please do let us 
>>>> know what you think.
>>>> 
>>>> Bloc:
>>>> - Eventing saw a deep overhaul. They are now dispatched using the 
>>>> Announcements engine. The previous mechanism is still in place in order to 
>>>> help people compare the impact. In the process, we also cleaned the 
>>>> propagation of events, and we made them debuggable through inspector 
>>>> extensions:
>>>> https://twitter.com/feenkcom/status/955086133519618048
>>>> https://twitter.com/feenkcom/status/946482609680539649
>>>> - Embedding Bloc elements in Morphic is even easier now:
>>>> https://twitter.com/feenkcom/status/946676667002556416
>>>> - We continued the work towards an interactive creation of a graphical 
>>>> scene:
>>>> https://twitter.com/feenkcom/status/948492946541858816
>>>> - Theme experiment
>>>> 
>>>> GT:
>>>> - The documentation of Mondrian is available when you download the code 
>>>> and can be viewed using GT Documenter:
>>>> https://twitter.com/feenkcom/status/939394586115563520
>>>> - The Mondrian extensions of BlElement are now extracted in a more general 
>>>> package that enables Bloc elements to be used in graph scenes.
>>>> 
>>>> Have fun,
>>>> The feenk team
>>>> 
>>>> 
>>>> --
>>>> www.tudorgirba.com
>>>> www.feenk.com
>>>> 
>>>> "Obvious things are difficult to teach."
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Moose-dev mailing list
>>>> moose-...@list.inf.unibe.ch
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>> 
>>> 
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr
>>> http://www.synectique.eu / http://www.pharo.org
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>> 
>>> ___
>>> Moose-dev mailing list
>>> moose-...@list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Beauty is where we see it."
>> 
>> 
>> 
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Every thing should have the right to be different."

Re: [Pharo-users] [Moose-dev] Re: feenk log

[Tudor Girba]

Hi,

There is a difference in performance. The Announcement is slower (about 2-3x 
slower). However, for 1M events the difference is measured in a 200-400ms, 
which is very small.

The benefit of using Announcement is that we can reuse the tooling around 
Announcement, such as blogging and debugging.

Still, the way it is used in Bloc is different from the typical usage in that 
Bloc registers to all Events (which are Announcements) and then dispatches 
through them to specific Element method (like BlEventListener>>clickEvent:). 
Still the cool thing is that you also can still register from the outside to a 
specific event using a normal when:do:.

We will write a piece of doc about it.

Cheers,
Tudor


> On Jan 21, 2018, at 4:46 PM, Stéphane Ducasse <stephane.duca...@inria.fr> 
> wrote:
> 
> this looks really cool. 
> For the event I remember the discussion with glenn about the difference and I 
> forgot. 
> 
> Stef
> 
>> On 21 Jan 2018, at 15:54, Tudor Girba <tu...@tudorgirba.com> wrote:
>> 
>> Hi,
>> 
>> Here is an update of the work on Bloc and GT. As always, please do let us 
>> know what you think.
>> 
>> Bloc:
>> - Eventing saw a deep overhaul. They are now dispatched using the 
>> Announcements engine. The previous mechanism is still in place in order to 
>> help people compare the impact. In the process, we also cleaned the 
>> propagation of events, and we made them debuggable through inspector 
>> extensions:
>> https://twitter.com/feenkcom/status/955086133519618048
>> https://twitter.com/feenkcom/status/946482609680539649
>> - Embedding Bloc elements in Morphic is even easier now:
>> https://twitter.com/feenkcom/status/946676667002556416
>> - We continued the work towards an interactive creation of a graphical scene:
>> https://twitter.com/feenkcom/status/948492946541858816
>> - Theme experiment
>> 
>> GT:
>> - The documentation of Mondrian is available when you download the code and 
>> can be viewed using GT Documenter:
>> https://twitter.com/feenkcom/status/939394586115563520
>> - The Mondrian extensions of BlElement are now extracted in a more general 
>> package that enables Bloc elements to be used in graph scenes.
>> 
>> Have fun,
>> The feenk team
>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Obvious things are difficult to teach."
>> 
>> 
>> 
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

[Pharo-users] feenk log

[Tudor Girba]

Hi,

Here is an update of the work on Bloc and GT. As always, please do let us know 
what you think.

Bloc:
- Eventing saw a deep overhaul. They are now dispatched using the Announcements 
engine. The previous mechanism is still in place in order to help people 
compare the impact. In the process, we also cleaned the propagation of events, 
and we made them debuggable through inspector extensions:
https://twitter.com/feenkcom/status/955086133519618048
https://twitter.com/feenkcom/status/946482609680539649
- Embedding Bloc elements in Morphic is even easier now:
https://twitter.com/feenkcom/status/946676667002556416
- We continued the work towards an interactive creation of a graphical scene:
https://twitter.com/feenkcom/status/948492946541858816
- Theme experiment

GT:
- The documentation of Mondrian is available when you download the code and can 
be viewed using GT Documenter:
https://twitter.com/feenkcom/status/939394586115563520
- The Mondrian extensions of BlElement are now extracted in a more general 
package that enables Bloc elements to be used in graph scenes.

Have fun,
The feenk team


--
www.tudorgirba.com
www.feenk.com

"Obvious things are difficult to teach."