Re: glamorous toolkit: v0.4.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Luke Gorrie
On Fri, 28 Dec 2018 at 14:03, Tudor Girba <[hidden email]> wrote:
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?

IIRC, I started with the Mondrian API, but switched to Roassal API to expose the functionality and extension points that I needed. Maybe wasn't necessary, I'm not sure, but Mondrian felt like a "middle man."

So in the new universe I could try again to formulate it with Mondrian or otherwise switch to... is there a counterpart to Roassal?
Here is the meat of the code for the visualization:

It's not much. Separately there is some code for defining the shapes and colours of the nodes, and filtering which edges should be considered for the tree layout.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Tim Mackinnon-5
In reply to this post by Sean P. DeNigris
I had a similar question - is this a heads-up of a future fork (and a future commercial offering?). Or is it more like there will be Pharo lean/dev (the current pharo) and a fuller/fatter Feenk, that is pharo based but augments with a richer set of tools? Or are we experimenting with a potential new pharo direction that drops the existing tools if the community likes it?

Either way - I like the work, I just want to be careful of any politics.

Tim


On Sat, 22 Dec 2018, at 4:58 PM, Sean P. DeNigris wrote:
> Tudor Girba-2 wrote
> > 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.
>
> Does this mean it will offer Pharo an alternative UI (what I think you
> mean), or that the final product will not be Pharo-based?
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Moose-f1310756.html
> _______________________________________________
> Moose-dev mailing list
> https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Offray Vladimir Luna Cárdenas-2
In reply to this post by Tudor Girba-2

On 28/12/18 8:03, Tudor Girba wrote:
>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <[hidden email]> 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



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Kjell Godo
In reply to this post by Tudor Girba-2


i don’t know enough to to rezound much more than 
     a critic who never read the book . ie cliff notes tool bound
it just looks really powerful and all the words like cool do sound
no doubt it makes a lot of(      other      )languages jealous enough to route
     and do some gremlin’s pout i may or may not have heard about   not quite sure in redoubt
     winjing why should they get this gold they’re goofy and we’re out in the speed cold n unsouled
     we can’t image ine it why should it even exist if not existing then it shall not blind or be missed
     apon this even being true don’t look at me I’m asking you it’s pure : what a poverty of mind
          just spin up some images and to thy text files be kind         no offense to emacs bind
but i know nothing     i don’t know a thing
and it makes me really really want to get this latest click moose bling
     with all the stuffing puffing and the kaboose thing
     and stripped Pharo’s unglamorous to thy skript loosed to clamour us and cut it loose in styled
and every minute I’m not doing this makes me   feel   a most silly goose   unlawfully beguiled
     and i do protest I’m gonna be a silly goose for too longa this silly while




On Fri, Dec 28, 2018 at 05:04 Tudor Girba <[hidden email]> wrote:

> On Dec 28, 2018, at 1:08 PM, Kjell Godo <[hidden email]> wrote:
>
> WOW

:)

What part of it do you like?

Cheers,
Doru


> On Thu, Dec 20, 2018 at 01:57 Tudor Girba <[hidden email]> 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 <[hidden email]> wrote:
> >
> > On Fri, 14 Dec 2018 at 05:13, Tudor Girba <[hidden email]> 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.
> >
> >
> > <gt-documenter-magic-markup.gif><gt-0-4-0.png>_______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > 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
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

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





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Ben Coman
This post seems to have come through from the moose mailing list...
 
On Sat, 29 Dec 2018 at 02:59, Kjell Godo <[hidden email]> wrote:
i don’t know enough to to rezound much more than 
     a critic who never read the book . ie cliff notes tool bound
it just looks really powerful and all the words like cool do sound
no doubt it makes a lot of(      other      )languages jealous enough to route
     and do some gremlin’s pout i may or may not have heard about   not quite sure in redoubt
     winjing why should they get this gold they’re goofy and we’re out in the speed cold n unsouled
     we can’t image ine it why should it even exist if not existing then it shall not blind or be missed
     apon this even being true don’t look at me I’m asking you it’s pure : what a poverty of mind
          just spin up some images and to thy text files be kind         no offense to emacs bind
but i know nothing     i don’t know a thing
and it makes me really really want to get this latest click moose bling
     with all the stuffing puffing and the kaboose thing
     and stripped Pharo’s unglamorous to thy skript loosed to clamour us and cut it loose in styled
and every minute I’m not doing this makes me   feel   a most silly goose   unlawfully beguiled
     and i do protest I’m gonna be a silly goose for too longa this silly while

Kjell,

This is awkward. Some of your posts seem human produced...

But such off topic poetry is not appropriate, doubly so since the above looks bot generated.
There have been several incidents in the past where the community has requested your account be blocked
in response to such posts.  

The key red flag for me is that you've never responded directly to requests to block your account.

On Wed, 15 Aug 2018 at 06:14, Eliot Miranda <[hidden email]> wrote:
Hi All,

    I have to say that Kjell has never posted anything I have found helpful or interesting or even on topic.  I suggest blocking him.

On Thu, 18 Jan 2018 at 19:09, Tudor Girba <[hidden email]> wrote:
Should we not block this account? It looks generated … although it is quite scary how not easy it is to not figure this out.

On Sat, 1 Aug 2015 at 21:46, Marcus Denker <[hidden email]> wrote:
We will kick you out if you send crap to this list. 
One more mail like that and you are out.
 
 On Sat, 1 Aug 2015 at 22:38, Marcus Denker <[hidden email]> wrote:
I have removed the sender from the list.
The pharo board decided already last year (from the time when the mails that he is answering now)
were written that these emails are just disturbing our work, with no positive value whatsoever.


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Tudor Girba-2
In reply to this post by Offray Vladimir Luna Cárdenas-2
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 <[hidden email]> wrote:
>
>
> On 28/12/18 8:03, Tudor Girba wrote:
>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <[hidden email]> 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."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Tudor Girba-2
In reply to this post by Tim Mackinnon-5
Hi,

We have no interest in playing politics in any way. That is why we are making explicit both our aims and the ways in which we work.

As I mentioned, we work as a team and our goal is specifically to offer a different alternative to approaching programming. At the moment, this is different from the goal of Pharo, although the two are likely not incompatible. Interestingly, this goal is not far from the work that happened around Moose. Humane assessment was born in the Moose context, and in fact, the first GT was developed for several years in the context of Moose as well.

The most concrete thing that people see from our current effort is the new GT interface, but we are building other things as well. First, GT has tools inside that are interesting for other purposes. We mentioned recently Releaser, a new tool that we think solves a significant problem in Pharo. Also, the Examples engine might be interesting, too. And so is the Bloc stack in which we invested heavily. Less obvious is that we have created xdoc, a format and associated technology for sharing executable documents. We also develop the moldable development approach that is enabled by the new kinds of tools.

From a concrete perspective, indeed, we are only relying on about half of the current Pharo (the language&runtime, but not the graphics&environment). At the same time, most code we build is available as open-source in ways that are compatible with Pharo both from a license and from a technical perspective. At present time, our code loads cleanly and works in the latest Pharo without any modifications required for Pharo.

While we love working in Pharo, we are not the ones that decide its course, and we leave the decisions of what will happen with Pharo with the Pharo team.

Cheers,
Doru



> On Dec 28, 2018, at 4:44 PM, Tim Mackinnon <[hidden email]> wrote:
>
> I had a similar question - is this a heads-up of a future fork (and a future commercial offering?). Or is it more like there will be Pharo lean/dev (the current pharo) and a fuller/fatter Feenk, that is pharo based but augments with a richer set of tools? Or are we experimenting with a potential new pharo direction that drops the existing tools if the community likes it?
>
> Either way - I like the work, I just want to be careful of any politics.
>
> Tim
>
>
> On Sat, 22 Dec 2018, at 4:58 PM, Sean P. DeNigris wrote:
> > Tudor Girba-2 wrote
> > > 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.
> >
> > Does this mean it will offer Pharo an alternative UI (what I think you
> > mean), or that the final product will not be Pharo-based?
> >
> >
> >
> > -----
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Moose-f1310756.html
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>

--
www.feenk.com

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





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Offray Vladimir Luna Cárdenas-2
In reply to this post by Tudor Girba-2
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 one, please point me to it.
>
> Cheers,
> Doru
>
>
>> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
>>
>>
>> On 28/12/18 8:03, Tudor Girba wrote:
>>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <[hidden email]> 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."
>
>
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Tudor Girba-2
Hi,

Thanks for the link. For some strange reason, I do not see the linked email in my inbox.

I am happy to hear that you could install GT.


>   * The new interfaces and some demo of the graphical elements look
>     pretty good
>   * After just some operations including window resizing I just get the
>     Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png).

Indeed, that is a known problem:
https://github.com/feenkcom/gtoolkit/issues/64


>   * I like the little triangles to expand thing in the document and the
>     run buttons for embedded code, and the "embeddability" of elements
>     in the document in a tree like fashion, which of course could lead
>     to documents that embed pieces of documents, which embed pieces of
>     documents… But the dual panel view of code in one side with
>     results in the right panel of old GT didn't tend to create such
>     "recursion". This dual modal view is the same of
>     Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi)
>     for interactive documentation and I would like to see examples more
>     in that line... but I don't know how it suits the philosophy behind
>     Documenter, which seems more aligned to a modal non dual view of the
>     document where you enter into edit mode once you click a piece of
>     the document and into a view mode once you are out of it (instead of
>     the proposed dual view). Would be nice to see is such dual view can
>     be used to directly operate on the rendered view and see changes in
>     the markup (i.e resizing an image in the rendered view changes the
>     value on the edit view).

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.

About the remark related "to documents that embed pieces of documents, which embed pieces of documents”: It is indeed possible to embed documents in documents, but I am not sure I understand where you see the issue appearing. Could you detail this part?



>   * I like the different view that a document can have, markup wise:
>     Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the
>     authoring part [4](https://i.imgur.com/Jc1T5Rm.png).

Interestingly, those extensions exist in the old Inspector as well.


>   * Its difficult to travel between the panels of a playground.
>     Previously you just make click in the lower circle representing the
>     panel you want to go at it was done
>     [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper
>     rectangle representing such panel has no effect
>     [6](https://i.imgur.com/8Obo3Ct.png).

For now, you have to rely on horizontal scrolling using a trackpad or mouse. Alternatively, Shift+scroll should also work. The upper part is not yet ready.


>   * Auto-completion and shortcuts for selecting text doesn't work well
>     on code cells of the new playground. Selecting whole words with Ctrl
>     arrow doesn't work, neither using down arrows to choose from
>     suggestions and even you can end with previous suggestions floating
>     around your playground [7](https://i.imgur.com/4awyIft.png)
>     [8](https://i.imgur.com/7qXc64b.png).

Indeed. These are known issues that we will tackle soon.


>   * The default data science example didn't work at all
>     [8](https://i.imgur.com/YhNb8el.png)

Nice catch. Thanks. The path of the file is incorrect when the image is copied.


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

> I used Moose to build the first Grafoscopio versions, but there was a
> lot of stuff that was related with software analysis that I didn't
> really need for reproducible interactive documentation and publishing
> nor for data science, activism and storytelling. So once old GT was
> integrated into Pharo with Spec I used a more minimal setup to deliver a
> more focused experience.
>
> I think that most times this relationship between Pharo and Moose can be
> of creative tension, one pushing the boundaries and the other offering a
> more stable experience where the innovations of the former are
> integrated and debugged. But even after using Moose as a fully
> integrated vision of what old GT have to offer in the back and front
> end, I didn't see any migration path from previous Moose with the old GT
> to the current GT, which is kind of worrisome. I understand the idea of
> forks in FLOSS as a way of dealing with politics behind the FLOSS
> movement and the relationship between different  visions and actors
> (individuals, communities, enterprises, foundations, associations and so
> on). It has happened before with Squeak, Pharo and Cuis and I'm fine
> with that. And I understand that a healthy relationship with the past
> means sometimes to break with it and jump into the future.
>
> That's why I think that the role of for profit and non for profit
> institutions is to balance a sense of momentum and stability around
> FLOSS. I would like to see a more clear road map for GT, knowing ahead
> where backward compatibility will be broken and why, which are the
> visions and, more importantly, how to participate and where are the
> boundaries. These are difficult tasks, but if the participation and
> boundaries are explored collectively, you can also know about the first
> ones (visions, versions, forks, compatibility). In that sense I think
> that Pharo is putting a good example: we have a clear road map document
> and participation process in the public repositories, there are public
> channels for users and developers and the private companies know about
> them, so they can put the boundaries about what is going to be done in
> the open, with the community, and what is to be kept closed inside
> company's frontiers and channels and the company's own velocity. I don't
> know if Feenk is planing something similar for its new vision, product
> and identity, and I don't know if the new alternative will have its own
> non-profit organizations as a neutral entity for all players using GT,
> but would be good to know about that, not because there are not people
> willing to jump into the future, but we would like to know to which
> future we're jumping on.  Without that I think that is a safer bet for
> myself to rely on Pharo and see how migration paths could ensure
> compatibility with my own past and the one of my local community using
> Pharo and GT based tools. I hope that the open source nature of both
> products (Pharo and new GT) will ease the cross-pollination of the more
> interesting ideas, even without sharing code, visions or UI.

We do not regard our work as an evolution, and we are not concerned with backwards compatibility. We are not trying to be completely different to what we had before, but being compatible is simply not a goal. For example, extending oldInspector is usually a matter of a dozen lines. Extending the new Inspector works in a similar way, but with a slightly different API that is needed because of the new infrastructure. The migration is not a pain, and it can happen seamlessly as I described in the mail to Luke.

I understand how from your point of view as a user of Pharo and oldGT you regard backward compatibility as important. However, we look at things differently. We think that development can be enhanced both from an efficiency and from a happiness point of view with a significant degree. When something like this is possible, the opportunities are different, too. For example, backward compatibility is about limiting costs. However, when the profit promise can be large, some costs can be worthwhile and are to be considered investments.

What do we mean by profit? For example, what would it be worth for a company to have the non-technical people literally pair and understand the internal details of the domain model? Compared to what exists now, that can be invaluable and we think that following moldable development this will be a natural by product. Another example: what would it worth for a developer of a library to build a live documentation with a marginal effort that simply leverages the testing effort? It can be invaluable, 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 <[hidden email]> 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 one, please point me to it.
>>
>> Cheers,
>> Doru
>>
>>
>>> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
>>>
>>>
>>> On 28/12/18 8:03, Tudor Girba wrote:
>>>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <[hidden email]> 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."
>>
>>

--
www.feenk.com

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








_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Offray Vladimir Luna Cárdenas-2

Hi Doru,

On 29/12/18 15:50, Tudor Girba wrote:
Hi,

Thanks for the link. For some strange reason, I do not see the linked email in my inbox.

It was also absent from the web archives of the Pharo mailing list and, as I'm not subscribed to Pharo-Dev I always get a warning about a rejected message (I don't know if this is related somehow to the mails being hard to find). Anyway, I'm hitting "Reply all" button so you'll have the answers from this thread also in your personal mail (and have stopped cc to Pharo-Dev).



I am happy to hear that you could install GT.

Thanks.



      
  * The new interfaces and some demo of the graphical elements look
    pretty good
  * After just some operations including window resizing I just get the
    Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png).
Indeed, that is a known problem:
https://github.com/feenkcom/gtoolkit/issues/64

Maybe the main window should indicate more promptly about expected but strange behaviors and point to the Issues repository, somehow.



  * I like the little triangles to expand thing in the document and the
    run buttons for embedded code, and the "embeddability" of elements
    in the document in a tree like fashion, which of course could lead
    to documents that embed pieces of documents, which embed pieces of
    documents… But the dual panel view of code in one side with
    results in the right panel of old GT didn't tend to create such
    "recursion". This dual modal view is the same of
    Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi)
    for interactive documentation and I would like to see examples more
    in that line... but I don't know how it suits the philosophy behind
    Documenter, which seems more aligned to a modal non dual view of the
    document where you enter into edit mode once you click a piece of
    the document and into a view mode once you are out of it (instead of
    the proposed dual view). Would be nice to see is such dual view can
    be used to directly operate on the rendered view and see changes in
    the markup (i.e resizing an image in the rendered view changes the
    value on the edit view).
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. This seems kind of strange in interactive documentation, because of the bad habits that WYSIWYG word processors installed on authors, but most of the time What You See Is **Only** What You Get, but you need enable comments to yourself, use admonitions, refer to bibliographic keys, and so son. That's why I think is a healthy practice to separate both, composition and typeseting and think in a bi-modal way, instead of a conflated way, in a similar fashion to what Bret Victor demos show for working with graphics and code in a bi-modal way [2][3]. I have experience, first hand, in "documentathons" using CodiMD, how document authors could benefit from bi-modal thinking for their documents, by showing side by side, Markdown and the rendered document changing in real time. I would like something similar for the Pharo environment.
[1] http://ricardo.ecn.wfu.edu/~cottrell/wp.html
[2] http://worrydream.com/#!/InventingOnPrinciple
[3] https://i.imgur.com/vi6bX21.png
[4] https://en.wikipedia.org/wiki/GNU_TeXmacs

TeXmacs[4] has a really good What You See Is What You *Mea*n (WYSIWYM) editor that conflates composition and typography, but it works like a charm, specially while you're writing mathematics that I have not seen elsewhere (not even in comercial word processors). But when you start to push boundaries (for example by using non traditional templates) the visual approach shows its limits compared to a bi-modal editor.



About the remark related "to documents that embed pieces of documents, which embed pieces of documents”: It is indeed possible to embed documents in documents, but I am not sure I understand where you see the issue appearing. Could you detail this part?

Some times when I was browsing the examples I made click on an icon that shows the document embedded in the document where the link appeared and then that happened again. I can't remember the icon or reproduce the experience. It seems that rendering in the lateral panel is working and I don't know how to get this nested embedding behavior again.



  * I like the different view that a document can have, markup wise:
    Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the
    authoring part [4](https://i.imgur.com/Jc1T5Rm.png).
Interestingly, those extensions exist in the old Inspector as well.

Yes I saw them previously, but the editor make this more... explicit/"explorable"... maybe is related with the rendering, but they seem better now.



      
  * Its difficult to travel between the panels of a playground.
    Previously you just make click in the lower circle representing the
    panel you want to go at it was done
    [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper
    rectangle representing such panel has no effect
    [6](https://i.imgur.com/8Obo3Ct.png).
For now, you have to rely on horizontal scrolling using a trackpad or mouse. Alternatively, Shift+scroll should also work. The upper part is not yet ready.

In Linux those combinations don't work. Any way to get the previous one click behavior? What is the rationale behind having to press more keys, instead of the previous simpler approach? Some collision between shortcuts?



      
  * The default data science example didn't work at all
    [8](https://i.imgur.com/YhNb8el.png)
Nice catch. Thanks. The path of the file is incorrect when the image is copied.


Glad to help :-)


[...]


I used Moose to build the first Grafoscopio versions, but there was a
lot of stuff that was related with software analysis that I didn't
really need for reproducible interactive documentation and publishing
nor for data science, activism and storytelling. So once old GT was
integrated into Pharo with Spec I used a more minimal setup to deliver a
more focused experience.

I think that most times this relationship between Pharo and Moose can be
of creative tension, one pushing the boundaries and the other offering a
more stable experience where the innovations of the former are
integrated and debugged. But even after using Moose as a fully
integrated vision of what old GT have to offer in the back and front
end, I didn't see any migration path from previous Moose with the old GT
to the current GT, which is kind of worrisome. I understand the idea of
forks in FLOSS as a way of dealing with politics behind the FLOSS
movement and the relationship between different  visions and actors
(individuals, communities, enterprises, foundations, associations and so
on). It has happened before with Squeak, Pharo and Cuis and I'm fine
with that. And I understand that a healthy relationship with the past
means sometimes to break with it and jump into the future.

That's why I think that the role of for profit and non for profit
institutions is to balance a sense of momentum and stability around
FLOSS. I would like to see a more clear road map for GT, knowing ahead
where backward compatibility will be broken and why, which are the
visions and, more importantly, how to participate and where are the
boundaries. These are difficult tasks, but if the participation and
boundaries are explored collectively, you can also know about the first
ones (visions, versions, forks, compatibility). In that sense I think
that Pharo is putting a good example: we have a clear road map document
and participation process in the public repositories, there are public
channels for users and developers and the private companies know about
them, so they can put the boundaries about what is going to be done in
the open, with the community, and what is to be kept closed inside
company's frontiers and channels and the company's own velocity. I don't
know if Feenk is planing something similar for its new vision, product
and identity, and I don't know if the new alternative will have its own
non-profit organizations as a neutral entity for all players using GT,
but would be good to know about that, not because there are not people
willing to jump into the future, but we would like to know to which
future we're jumping on.  Without that I think that is a safer bet for
myself to rely on Pharo and see how migration paths could ensure
compatibility with my own past and the one of my local community using
Pharo and GT based tools. I hope that the open source nature of both
products (Pharo and new GT) will ease the cross-pollination of the more
interesting ideas, even without sharing code, visions or UI.
We do not regard our work as an evolution, and we are not concerned with backwards compatibility. We are not trying to be completely different to what we had before, but being compatible is simply not a goal. For example, extending oldInspector is usually a matter of a dozen lines. Extending the new Inspector works in a similar way, but with a slightly different API that is needed because of the new infrastructure. The migration is not a pain, and it can happen seamlessly as I described in the mail to Luke.

I understand how from your point of view as a user of Pharo and oldGT you regard backward compatibility as important. However, we look at things differently. We think that development can be enhanced both from an efficiency and from a happiness point of view with a significant degree. When something like this is possible, the opportunities are different, too. For example, backward compatibility is about limiting costs. However, when the profit promise can be large, some costs can be worthwhile and are to be considered investments. 

As I said, I don't have problems with breaking with the past as a healthy relationship with it. This has happened before. My issue is with not knowing that a jump will be done or where are we jumping on. And also with the places where the process will be open or close. Maybe the way to communicate advances is to work enclosed first and then releasing your prototypes to the open, maybe is about having public issue trackers with fixed deadlines... I don't know what works better for the interaction between feenk and the wider Pharo community, but I think that if the process is more explicit, we, the users of Pharo and old GT can adjust expectations. I really don't know if the cost are worthwhile ATM because I don't know what is the next step of the path in new GT. I like its new rendering  features, but I have just a static picture at each step and I don't know where the future is going or how to get there. For me is not about fixed futures but more about open processes and boundaries, as I told before, and with those known we can explore uncertain futures together.


What do we mean by profit? For example, what would it be worth for a company to have the non-technical people literally pair and understand the internal details of the domain model? Compared to what exists now, that can be invaluable and we think that following moldable development this will be a natural by product. Another example: what would it worth for a developer of a library to build a live documentation with a marginal effort that simply leverages the testing effort? It can be invaluable, and we think this is trivially possible.

Maybe those offerings are invaluable... I really don't know as they're not closer to my context for live documentation, which is not for developers... once the roadmap and processes become clearer I could better asset that profit scenario.


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. 

Yes, more that a roadmap, it seems more like a mission with some glimpses of what forms it can take. As said, I don't have problems with exploring unknowns together or discontinuities with the past. The main issue is more processes and boundaries. I don't want to invest time in a technology that wold be jumping to something incompatible in the future and the time I notice that is when the new glimpse is released.


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.

Well, once those guiding principles and ways to engage are more explicit and think that those of us who have been using GT will now how to and how much engage with the possibilities that feenk is building (they look impressive, as I said, but would like to know where/when quantum leaps are happening).


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.

Yes I will go slower. More than stability and predictability, I'm looking for known processes and boundaries.



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.

As I said, the fork would be UI wise, not in the core technologies. But some of us are relaying in the possibilities that current and future UI experiences are providing in Pharo to orientate our own developments and local communities.

This critics mean to be constructive, explicitly trying to reach clarities in an open way and I hope that serves the wider Pharo communities. The work feenk is doing is a good showcase of interesting future possibilities and is important to have those futures open for the community and to know how to traverse/connect them.

Cheers,

Offray



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
12