glamorous toolkit: v0.4.0

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

glamorous toolkit: v0.4.0

Tudor Girba-2
Hi,

Things are moving fast in the glamorous land. We now reached v0.4.0:

There are several significant advances in this version. The first thing to note is that v0.4.0 is a reproducible version that can be loaded with:
Metacello new
   baseline: 'GToolkit';
   repository: '<a href="github://feenkcom/gtoolkit:v0.4.0/src" class="">github://feenkcom/gtoolkit:v0.4.0/src';
   load.
The version was created with Releaser the new member of GT that is able to release deeply nested projects:


The rest of the environment has seen a few key changes as well:

- Documenter received support for dynamic markup edit. This is an almost magic ability that makes the markup appear when the cursor nears the markup. With this we have reached a seamless experience that supports both viewing without markup and editing on demand.

- Playground uses Coder and snippets are now collapsable.

- The Inspector updates when the code changes.
https://twitter.com/feenkcom/status/1072581283925159936

- The Meta view from Inspector was enhanced to show the super classes and method categories, each of these act list filters. On top of that, we can also filter methods by name.
https://twitter.com/feenkcom/status/1072223641583149057

A more complete list of issues we addressed is found here:
https://github.com/feenkcom/gtoolkit/milestone/2?closed=1


Please do let us know what you think .. and, of course, what you feel.

Have fun,
The feenk team



--
www.feenk.com

“How do you feenk today?"
Reply | Threaded
Open this post in threaded view
|

Re: glamorous toolkit: v0.4.0

Richard Sargent
Administrator
Wow!!!


On Thu, Dec 13, 2018, 18:49 Tudor Girba <[hidden email] wrote:
Hi,

Things are moving fast in the glamorous land. We now reached v0.4.0:

There are several significant advances in this version. The first thing to note is that v0.4.0 is a reproducible version that can be loaded with:
Metacello new
   baseline: 'GToolkit';
   repository: 'github://feenkcom/gtoolkit:v0.4.0/src';
   load.
The version was created with Releaser the new member of GT that is able to release deeply nested projects:


The rest of the environment has seen a few key changes as well:

- Documenter received support for dynamic markup edit. This is an almost magic ability that makes the markup appear when the cursor nears the markup. With this we have reached a seamless experience that supports both viewing without markup and editing on demand.

- Playground uses Coder and snippets are now collapsable.

- The Inspector updates when the code changes.
https://twitter.com/feenkcom/status/1072581283925159936

- The Meta view from Inspector was enhanced to show the super classes and method categories, each of these act list filters. On top of that, we can also filter methods by name.
https://twitter.com/feenkcom/status/1072223641583149057

A more complete list of issues we addressed is found here:
https://github.com/feenkcom/gtoolkit/milestone/2?closed=1


Please do let us know what you think .. and, of course, what you feel.

Have fun,
The feenk team



--
www.feenk.com

“How do you feenk today?"

gt-documenter-magic-markup.gif (1M) Download Attachment
gt-0-4-0.png (90K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Gour
In reply to this post by Tudor Girba-2
On Fri, 21 Dec 2018 17:02:48 -0500
Offray Vladimir Luna Cárdenas
<[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Offray Vladimir Luna Cárdenas-2

On 22/12/18 10:44, Gour wrote:
> On Fri, 21 Dec 2018 17:02:48 -0500
> Offray Vladimir Luna Cárdenas
> <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Gour
On Sat, 22 Dec 2018 12:53:16 -0500
Offray Vladimir Luna Cárdenas
<[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Offray Vladimir Luna Cárdenas-2

On 23/12/18 3:21, Gour wrote:
> On Sat, 22 Dec 2018 12:53:16 -0500
> Offray Vladimir Luna Cárdenas
> <[hidden email]> 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&atb=v76-7&iar=videos&iax=videos&ia=videos&iai=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



Reply | Threaded
Open this post in threaded view
|

désabonnement

Pharo Smalltalk Users mailing list
In reply to this post by Tudor Girba-2


    
Reply | Threaded
Open this post in threaded view
|

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

khinsen
In reply to this post by Tudor Girba-2
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.

Reply | Threaded
Open this post in threaded view
|

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

Pharo Smalltalk Users mailing list
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 <[hidden email]> 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."


Reply | Threaded
Open this post in threaded view
|

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

Pharo Smalltalk Users mailing list
Hi,

Thanks Konrad for the Sketch-n-Sketch link.  I think that you hit the
point about having multiple editors and views for the same object. I
think that for interactive documentation that goes beyond software, that
is needed, specially when you are targeting single source input and
multi device/format output (like here [1]). Several Markdown variants
are targeting such scenario, that includes interactive documentation,
but is not their only concern. ATM seems that new GT is pretty tied to
Pillar and software documentation (which is fine, but not the path I'm
primarily interested).

[1] https://mutabit.com/repos.fossil/mapeda/

I will see what future Pharo 7 based toolkits bring on that front.

Cheers,

Offray

On 1/1/19 16:50, Tudor Girba via Pharo-users wrote:


Reply | Threaded
Open this post in threaded view
|

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

Pharo Smalltalk Users mailing list
In reply to this post by Pharo Smalltalk Users mailing list
Hi Doru and Offray,

Tudor Girba via Pharo-users <[hidden email]> writes:

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

Or when the output reflects only a part of the input document. I suspect
Offray has the same kind of application in mind as myself, knowing a bit
of his work, and it is indeed a bit different from what you are
designing GT for. What we do (mainly) is documenting computations, not
software. A computation consists of code, input data, and selected
results.  This inevitably requires some metadata that needs to be
editable but should not necessarily appear in the output. The most basic
technology for documenting computations is the notebook (Mathematica,
Jupyter, ...) where the metadata is just the cell structure (which does
show in the output). More sophisticated systems (Emacs OrgMode for
example) allow more fine-tuning, making for much nicer output, but also
requiring quite a bit more metadata.

> 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

From what I know about Pillar, I agree. The way this is handled in
Documenter is indeed very appropriate for very simple markup like that.
And simple markup is highly desirable whenever sufficient.

> 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

The closest I have seen is MarkText: https://marktext.github.io/website/
Its "focus mode" works much like Documenter in principle, but feels less
fluent somehow.


Offray Vladimir Luna Cárdenas via Pharo-users
<[hidden email]> writes:

> but is not their only concern. ATM seems that new GT is pretty tied to
> Pillar and software documentation (which is fine, but not the path I'm
> primarily interested).

Me neither, but I still find a lot of interesting ideas in GT and I
suspect that a tool closer to my interests could be built with reasonable
effort from the bricks that GT provides.

My holy grail is a document that describes both software and
computations, combining the features of notebooks and literate
programming into a hypertext-like system in which I can start at the
surface (the computation) and "zoom in" to any part of the software,
getting documentation and not just source code.

Cheers,
  Konrad.

Reply | Threaded
Open this post in threaded view
|

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

Sean P. DeNigris
Administrator
Pharo Smalltalk Users mailing list wrote
> My holy grail is a document that describes both software and
> computations

Yes!!! Capturing mindshare in the data analysis field would be *huge* for
Pharo/GT because there are a lot of people who are new and view
languages/environments as means to an end, and hence seem to be much less
poisoned against blue plane ideas by years of Stockholm syndrome with
obsolete but common technologies.



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean