Hi again :-),

I forgot to mention about the Spec2 migration plans, so a (hopefully)
short comment on that.

Last ESUG I talked with Guille and Esteban about combining Spec(1) and
Spec2 in a single interface. The idea is to be able to embed Spec old
widgets into Spec2, as they are progressively migrated. and now I'm
needing Johan Fabry's Playground package[1] to embed playgrounds in the
Grafoscopio notebooks. As the Spec2 migration completes and the
rewriting is done, Grafoscopio 2.x series will be launched.

[1] http://static.smalltalkhub.com/jfabry/Playground/

Any advice, bug reporting, bug fixing or comments on Grafoscopio are
greatly appreciated.

Cheers,

Offray

On 5/08/20 1:44 p. m., Offray Vladimir Luna Cárdenas wrote:
> Hi,
>
> On 5/08/20 9:43 a. m., tbrunz wrote:
>>>> Okay, I'll do that. But this brings up a more general question... 
>>>>
>>>> If I wanted to add a diagram, or maybe a document with equations
>>> (rendered 
>>>> in LaTex), then a class comment wouldn't work. 
>>>>
>>>> ...Unless that's intended to be part of the newer format?? 
>>> Microdown supports latex via external services (I should check that the 
>>> implementation uses the same cache than the one for pictures). 
>>> For diagram you can use png but we will have to spot glitches. 
>> One more thought on this...  I assume you've seen Jupyter Notebooks? 
>> They're starting to see some use where I work (we now have our own
>> 'enterprise server').  I recently took an intro class to see how it works,
>> and how to use them.
>>
>> How much of a "Jupyter-style" notebook capability would the community be
>> interested in?  By that I mean having the ability to mix 'rich'
>> documentation with code and data to produce interactive 'notebooks' with
>> similarities to what Jupyter does -- but simpler!  Jupyter is much too
>> complicated...
> I can't speak for the wider community, but I think that there is some
> interest as we have 3 Smalltalk interactive notebooks alternatives. Two
> of them where mentioned as a long talks [1][2] in the last ESUG and
> Grafoscopio was presented there also as a speed talk (someday I need to
> make a proper ESUG long talk, but being self funded means that my
> participation has been always confirmed in last moments). I share your
> concern about Jupyter being overcomplicated and in fact I started
> Grafoscopio in part out of my frustration with the incidental complexity
> in the Python notebook ecosystem (see [3]). We can be more lean and agile.
>
> [1]
> https://www.slideshare.net/esug/polyglot-notebooks-with-squeaksmalltalk-on-the-graalvm
> [2] https://www.slideshare.net/esug/building-a-scientific-workbench-in-pharo
> [3]
> http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html
>
> One of the differences of Grafoscopio with other Smalltalk notebooks is
> that is has an older diverse community (since 2015), beyond academia and
> software developers, including activists, journalists, librarians,
> philosophers, designers, among others. A key concern is to balance
> practical choices in such communities with the PhD research that created
> Grafoscopio (which was on Design and Creation with immersive community
> research). For example a simple extensible format to exchange
> Grafoscopio notebooks was an early concern and for that I used the
> excellent STON  format to mix documentation markup (Markdown) and Pharo
> code. Also I bridged external tools (Pandoc, Lua) to make format
> conversions (Markdown to LaTeX, HTML and PDF). The only other Smalltalk
> notebook I know that has a notebook format is Documenter's[4] Xdoc,
> which is a compressed folder mixing Pillar, JSON, txt and external files
> referred in the Pillar document. Our approach for that composed
> documents is to use Fossil [5], so such composed document or any
> collection of documents in fact is just a self contained Fossil
> repository, adding history, web interface and collaboration, while
> keeping documents self contained and storage simple and portable. It's
> aligned with ideas of SQLite as and application format[5a] and the
> Panama Papers 2016 prototypes [6][6a] even predate the idea of Fossil as
> a repository document[5b].
>
> [4] https://gtoolkit.com/components/documenter/
> [5] https://fossil-scm.org/
> [5a]
> https://www.pgcon.org/2014/schedule/attachments/319_PGCon2014OpeningKeynote.pdf
> [6] https://mutabit.com/offray/blog/en/entry/panama-papers-1
> [6a] https://mutabit.com/repos.fossil/panama-papers/dir
> [5b] https://fossil-scm.org/forum/forumpost/2ac0171524
>
> What I want to point is that different approaches to rich interactive
> documentation related with Pharo exist and they're exploring interesting
> alternative spaces beyond what Jupyter has done, despite of lacking the
> maturity, momentum and/or visibility behind Jupyter's. Scientific
> Workbench, Documenter, or polyglot notebooks for sure are providing
> valuable explorations and would be nice to be more aware of each others
> work and approaches.
>
>> What you describe for enhanced comments sounds like a step in that
>> direction...  Obviously Pharo is already oriented toward mixing code and
>> data in one document, and enhancing the comments moves it closer to a
>> notebook with richer documentation possibilities.  
>>
>> So it seems to me that generalizing this "enhanced document capability" and
>> making it more prominent (such as giving it its own type of window, rather
>> than it being a browser pane tied to the code?) would take it closer yet to
>> realizing a general, flexible "Pharo Notebooks" concept.
>>
>> My understanding is that Offray's Grafoscopio is essentially what I'm
>> describing, but maybe more oriented to data analysis & presentation..??  (He
>> can say better than I, as I'm not sure how accurate that is.)  I am thinking
>> of something that would include that, but maybe be more general-purpose.
> In Grafoscopio, interactive notebooks play an essential role with their
> own window and usage metaphor (document as an interactive tree). When I
> started, microdown was not in the radar and I would like explore further
> integration with it, instead of relaying on (excellent) Pandoc for
> format conversion. I have scripted Pandoc with Lua and is a pretty
> powerful combination and an interesting language, but nothing beats the
> Pharo's live coding experience and I would like to have that also for
> document exporters and (pre)processors. I think that Grafoscopio is
> already general concept-purpose enough. I wrote the Grafoscopio
> manual[7] in Pharo. We have done other non-coding and visualization
> documents on it, like porting the Data Journalism Handbook[8][8a] and
> Data Feminism Book[9][9a] to our pocket infrastructures.
>
> [7]
> https://mutabit.com/repos.fossil/grafoscopio/uv/Docs/En/Books/Manual/manual.pdf
> [8] https://mutabit.com/repos.fossil/mapeda/doc/tip/intro.md
> [8a] https://mutabit.com/repos.fossil/mapeda/uv/mapeda.pdf
> [9] https://mutabit.com/repos.fossil/datafem/
> [9a] https://mutabit.com/repos.fossil/datafem/uv
>
> That being said, Grafoscopio was the "first real app" I ever did. The
> one that allowed me to go from scripting and formal modelling to
> programming and development. Its development has been directed by
> necessity and I have conceptual gaps and rookie code here and there.
> Development has been improved as I learn more, and I have being
> fortunate enough to have the attention and support from several
> community members, from testing and installing, to answering newbie
> questions, to my PhD internship, to bug reporting and even one offered
> to pair program with me (but I was too newbie, non-native speaker and
> shy to accept at that moment). Our last collaborator is Santiago
> Bragragnolo and he has been working on some refactoring.
>
> August will be kind of busy for me until 21th, but I would gladly be
> more involved with Grafoscopio after and meanwhile, retaking slowly some
> workshops and solving bugs.
>
>> Part of this idea is to feature a "semi-automated" subset of Spec2 that
>> makes it easier to get nice graphical UIs in a notebook fashion -- but does
>> not require as much depth of understanding Spec2.  (All of Spec2 allows
>> anyone to build anything.. but not everyone needs to build so much..?  This
>> is the value of frameworks and selectable motifs, yes?)  
>>
>> Could what I'm describing be a way for everyone to step easily into Spec2
>> when its full flexibility for making GUIs isn't needed (yet)?  By this I'm
>> implying code generators that create common/typical Spec2 framework classes
>> & methods that would make up the front-end of the 'documentation' element of
>> "Pharo Notebooks".  Pharo being Pharo, one could then customize further...
> My idea was to use a "self referential system" to explore the question
> about "How can we change the digital artifacts that change us?", from
> the perspective of a PhD in design and creation (not in computer
> science). But the idea was to create/introduce a tool inside a community
> (Grafoscopio) see how the community learn such tool and was able to
> change it. Interactive notebooks was my bridge to approach Pharo to
> non-coders. We are still far away of changing the tool itself, as Pharo
> and Grafoscopio has been kind of behind scenes in the projects we do and
> the more visible part has been documentation and a little bit of
> scripting. But I hope that the Indie Web workshops talked in other
> thread, make more visible the coding and scripting part so people can
> use it to customize their web sites, then notebooks and, at some point
> Grafoscopio or Pharo. The idea is to use interactive notebooks to
> automatize and customize Pharo to user needs and make such learning a
> bridge to customize Pharo.
>
>> Because "it's always easier to edit something than to create from a blank
>> page", yes?
>>
>> I can see Pharo taking away "market share" from Jupyter Notebooks, by being
>> simpler and easier to work with.  Data + Code + Document: All three elements
>> being "live" and interactive.  Pharo has the first two.. What about the
>> third?
> You could check the "Data continuum environment: data <-> queries <->
> code <-> visuals <-> docs" of the Panama Papers blog post [10], that
> points in the same direction.
>
> [10] https://mutabit.com/offray/blog/en/entry/panama-papers-1
>
> Cheers,
>
> Offray
>
>
>
>

Reply via email to