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

2018-12-29 Thread Offray Vladimir Luna Cárdenas 


On 23/12/18 3:21, Gour wrote:
> On Sat, 22 Dec 2018 12:53:16 -0500
> Offray Vladimir Luna Cárdenas
>  wrote:
>
>> I don't know yet, but I would like to use Tonel and some import/export
>> tools to use Fossil as my backend for file based storage instead of
>> Git. 
> I can fully understand you - using Fossil is so easy and safe in comparison
> with Git where one never knows...

Yes. I think that DVCS wise, developers imagination has been monopolized
by Git/GitHub. There are powerful simple little tools out there that are
practically outside of the developers' radar. Let's see what happens in
the Fossil + Pharo integration front.


>> These days are particularly slow in Colombia, but I will post advances
>> as soon as I have something.
> Thank you.
>
> Btw, I looked at Grafoscopio and it is interesting you had been looking
> or using tools like Leo editor, Pollen - I also considered Skribilo
> (Guile) - since I am also searching some toolchain to improve web
> publishing (paper output is not problem with LateX or ConTeXt) , but
> still haven't decided what to use/learn since learning Racket/Pharo
> requires some extra time until it can pay off (I want to stay focused
> on my writing and studying and not turn myself into programmer)...for
> now I'm still using Emacs/markdown-mode although in the past I spent
> time with both Aѕciidoc(tor) and rst markups.


I looked also at Skribilo in my search for more powerful tools for
interactive writing and documentation, and Emacs/OrgMode (see [1]). I
really liked the Racket approach of a meta programming tool for making
Domain Specific Languages (like the ones used for documentation). But in
the development front I think that Pharo/Smalltalk is hardly beaten by
anything, more if you're thinking not only in publishing (web, mobile or
print) but also in agile data visualization (see [2]). In that regard
becoming a coder was a valuable deviation from my research and study
that paid huge reward later in those fronts also.

[1]
https://duckduckgo.com/?q=devops+org+mode=v76-7=videos=videos=videos=dljNabciEGg

[2] https://vimeo.com/94724841

Is good to see more interest in interactive documentation in this
community. It seems that good times are coming.

Cheers,

Offray

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

2018-12-28 Thread Offray Vladimir Luna Cárdenas 


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

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

2018-12-28 Thread 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.
> > 
> > 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

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

2018-12-23 Thread Offray Vladimir Luna Cárdenas 
Hi Doru,

On 21/12/18 17:40, Tudor Girba wrote:
> Hi Offray,
>
> Thanks for describing your concerns.
>
Thanks to you for this conversation.


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

On the technical side, the 64Bit distribution in the smoothest
installation of the new GT I had have so far. Just unzip it and launch
the image and you are done! After that you are welcomed with a nice
welcome window with beauty typographical render and you can explore what
the GT has to offer and experience its potential first hand, which still
brings kind of a mixed experience:

  * 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).
  * 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).
  * 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).
  * 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).
  * 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).
  * The default data science example didn't work at all
[8](https://i.imgur.com/YhNb8el.png)


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

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

2018-12-23 Thread Gour 
On Sat, 22 Dec 2018 12:53:16 -0500
Offray Vladimir Luna Cárdenas
 wrote:

> I don't know yet, but I would like to use Tonel and some import/export
> tools to use Fossil as my backend for file based storage instead of
> Git. 

I can fully understand you - using Fossil is so easy and safe in comparison
with Git where one never knows...

> These days are particularly slow in Colombia, but I will post advances
> as soon as I have something.

Thank you.

Btw, I looked at Grafoscopio and it is interesting you had been looking
or using tools like Leo editor, Pollen - I also considered Skribilo
(Guile) - since I am also searching some toolchain to improve web
publishing (paper output is not problem with LateX or ConTeXt) , but
still haven't decided what to use/learn since learning Racket/Pharo
requires some extra time until it can pay off (I want to stay focused
on my writing and studying and not turn myself into programmer)...for
now I'm still using Emacs/markdown-mode although in the past I spent
time with both Aѕciidoc(tor) and rst markups.


Sincerely,
Gour

-- 
The senses, the mind and the intelligence are the sitting places
of this lust. Through them lust covers the real knowledge of the
living entity and bewilders him.

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

2018-12-22 Thread Offray Vladimir Luna Cárdenas 


On 22/12/18 10:44, Gour wrote:
> On Fri, 21 Dec 2018 17:02:48 -0500
> Offray Vladimir Luna Cárdenas
>  wrote:
>
>> Iceberg for code management (but supporting Fossil instead of Git).
> Fossil support in Iceberg is going to be officially supported?

I don't know yet, but I would like to use Tonel and some import/export
tools to use Fossil as my backend for file based storage instead of Git.
I think that the Git migration tool can be used for that (adding some
Fossil<->Git) scripts.

These days are particularly slow in Colombia, but I will post advances
as soon as I have something.

>
> Sincerely,
> Gour
>
Cheers,

Offray

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

2018-12-22 Thread Gour 
On Fri, 21 Dec 2018 17:02:48 -0500
Offray Vladimir Luna Cárdenas
 wrote:

> Iceberg for code management (but supporting Fossil instead of Git).

Fossil support in Iceberg is going to be officially supported?


Sincerely,
Gour

-- 
A person who has given up all desires for sense gratification,
who lives free from desires, who has given up all sense of
proprietorship and is devoid of false ego — he alone can
attain real peace.

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

2018-12-21 Thread Ben Coman 
On Sat, 22 Dec 2018 at 06:03, 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.

Was this on Windows? What was the fix for worked for you? (sorry its
easier to ask again than try to identify in the archives a previous
mention)

cheers -ben

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

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

2018-12-21 Thread 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 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

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

2018-12-21 Thread Offray Vladimir Luna Cárdenas 
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 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

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

2018-12-20 Thread 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."