August 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by Offray Vladimir Luna CÃ¡rdenas

Hi Ted, On 5/08/20 10:11 a.Â m., tbrunz wrote: > Hi Offray, > > I think you're addressing many of the same concerns as I am, with more of a > web/browser orientation perhaps... > > Which is good. Pharo can make nice, interactive web sites as well as nice, > interactive documents, can it not? For me web is kind of an "exportation format" as I dislike pretty much programming and writing in the native formats and languages that entangle the web (HTML, CSS, JavaScript) and they seem to me as verbose and/or inelegant. But web is an ubiquitous platform so thinking in it as a "compilation target" seems wise. I will try to Live code as much as I can in Pharo and export interactive documents to PDF and HTML as needed. That's the approach we have followed here so far and it had worked, so it will be the one we use for the indie web[1] workshops powered by Pharo. [1]https://indieweb.org/ > >> I think that we still can make a compelling case for wider audiences >> about Pharo and making it more visible. > I agree! What do the 'wider audiences' need? What will attract their > attention? Being visible is necessary, but is it sufficient? How can we > make them want to learn this new tool? (Everyone is so strained for time, > and attention is hard to come by these days...) Totally agree. We have this "attention economy" and almost everything/everyone is sending notifications and messages. Focused attention and effort are a luxury these days. In the case of grassroots communities, they have huge necessities but they're not a "compelling market". So what solves their needs is the stuff that will attract their attention and working with them and their needs is the best way to inquiry about this. Because we are in a Hackerspace and not in a startup or research facility, we are pretty close with such communities. Retaking the upcoming Indie Web workshop was a product of our voluntary work with grassroots communities. Grafoscopio interactive notebooks are a way to "package" expert knowledge in a low barrier way for non programmers in such communities. They can open and run the notebook and its nodes as they need and the output will be an updated web site that addresses their web presence needs not covered by big corp social media or overcomplicated CMS. The interactive notebook produces a static web site. And the idea is to use personalization of such community web sites via interactive notebooks to introduce them to programming (I will share more details as I have them). > >> agility and resilience are not properties of the >> overcomplicated web of today > So, so true... > >> .. making suggestions and helping us to improve the software >> engineering parts behind such problems/projects, > I am also interested in contributing to that. Better tools & methods for > solving the problems, better documentation to further understanding and > engagement, and better ways for users to employ the results. Thanks a lot :-)! I will be sharing the interactive notebooks we do and the software packages we create/modify for the Indie Web Worshops and the problems and solutions as they arise. While notebooks and workshops documentation will be mostly in Spanish, the code will be in English, so I think that this is a good bridge exercise and give us this intermediate level tutorials for Pharo. One of the things I like the most about Pharo and I remember and share in local workshops fromÂ Markcus' Nomads do not build Cathedrals talk[2] is the idea that to solve mode complex problems we need to change the infrastructure behind the projects. I tell the workshop attendants that Pharo's uniformity and readability is key to understand and traverse increased complexity in the platform (there is also a fight to decrease incidental complexity that is deeply rooted in Smalltalk cultures). So even if the "intermediate level" tutorials are a moving target the fact that we read/extend the infrastructure in a similar fashion, despite its complexity could help to address increasing complexity problems with such intermediate level entry knowledge, at least at the beginning. [2] https://www.slideshare.net/MarcusDenker/2014-esugcathedral Cheers, Offray

Aug. 5, 2020

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by Offray Vladimir Luna CÃ¡rdenas

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-… > [2] https://www.slideshare.net/esug/building-a-scientific-workbench-in-pharo > [3] > http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… > > 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… > [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… > [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 > > > >

Aug. 5, 2020

Re: [Pharo-users] Grafoscopio ported to Pharo 8.x and Git

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 5/08/20 1:32 p.Â m., Sean P. DeNigris wrote: > Offray Vladimir Luna CÃ¡rdenas-2 wrote >> Grafoscopio [1] has been ported to Pharo8.x and Git. > Great news :) > > Are you using Iceberg? > Thanks. And yes I'm using it, with community hosted Git/Gitea repositories[1]. Installation does a workaround [2] by downloading the repository and installing it from a local place. At some point I would like to provide Metacello "repo plugins", so it can understand messages like "#loadRepository: https://commutity.gitea.instance" and integrate Fossil and Git in a single repository. But for now, it's working. [1] https://code.tupale.co/Offray/Grafoscopio [2] https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme.md.html Cheers, Offray

Aug. 5, 2020

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by Offray Vladimir Luna CÃ¡rdenas

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-… [2] https://www.slideshare.net/esug/building-a-scientific-workbench-in-pharo [3] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… 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… [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… [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

Aug. 5, 2020

Re: [Pharo-users] Grafoscopio ported to Pharo 8.x and Git

by Sean P. DeNigris

Offray Vladimir Luna CÃ¡rdenas-2 wrote > Grafoscopio [1] has been ported to Pharo8.x and Git. Great news :) Are you using Iceberg? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 5, 2020

Re: [Pharo-users] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding while running Elegant Code image conversion example

by Offray Vladimir Luna CÃ¡rdenas

Thanks StÃ©phane and Tomo, I have added the working code to the GH issue thread. There is still need of testing images for the non working one? Offray On 5/08/20 4:00 a.Â m., StÃ©phane Ducasse wrote: > offrayÂ > > could you add your pictures to the bug entry > > https://github.com/pharo-project/pharo/issues/7043 > > S.Â > >> On 5 Aug 2020, at 07:53, Tomohiro Oda <tomohiro.tomo.oda(a)gmail.com >> <mailto:tomohiro.tomo.oda@gmail.com>> wrote: >> >> Offray, >> >> I tried it myself and found that the code works on some jpg pics and >> does not work on some other pics. >> For my case, using PluginBasedJPEGReadWriter instead of JPEGReadWriter >> solved the problem. >> >> Best Regards, >> --- >> tomo >> >> 2020å¹´8æ5æ¥(æ°´) 2:43 Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>>: >>> >>> Thanks Tomo, >>> >>> I tried your proposal, but now I get: "Error: marker C2 cannot be >>> handled" and still the exportation is not working. >>> >>> Cheers, >>> >>> Offray >>> >>> On 4/08/20 2:04 a. m., Tomohiro Oda wrote: >>>> Offray, >>>> >>>> Apparently, readStreamDo: should be binaryReadStreamDo: and >>>> writeStreamDo: should be binaryWriteStreamDo: . >>>> --- >>>> tomo >>>> >>>> 2020å¹´8æ4æ¥(ç«) 15:42 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>>> <mailto:stephane.ducasse@inria.fr>>: >>>>> Thanks for the report I confirm that I can reproduce the problem. >>>>> I do not know yet the answer. Now I think strange that we use a >>>>> characterStream for reading jpeg. >>>>> S. >>>>> >>>>> >>>>> On 3 Aug 2020, at 20:41, Offray Vladimir Luna CÃ¡rdenas >>>>> <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Today I was an introduction to Pharo. As usual, I asked the learner to >>>>> taste the environment and syntax by running the examples in excellent >>>>> Sven's Elegant Code[1] (BTW, can I translate snips of Â it to >>>>> Spanish?). >>>>> When she was adapting the example 6 about converting JPGs to PNGs, we >>>>> get the error reported in this mail's subject. I tried running her >>>>> example in my machine with her images and with my own and still I got >>>>> the same error. What are we missing? >>>>> >>>>> [1] >>>>> https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0 >>>>> >>>>> We are using Pharo 8.x on Manjaro Gnu/Linux 64 bits. >>>>> >>>>> Thanks, >>>>> >>>>> Offray >>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------- >>>>> StÃ©phane Ducasse >>>>> http://stephane.ducasse.free.fr / http://www.pharo.org >>>>> 03 59 35 87 52 >>>>> Assistant: Aurore Dalle >>>>> FAX 03 59 57 78 50 >>>>> TEL 03 59 35 86 16 >>>>> S. Ducasse - Inria >>>>> 40, avenue Halley, >>>>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>>>> Villeneuve d'Ascq 59650 >>>>> France >>>>> >>> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.orgÂ > 03 59 35 87 52 > Assistant: Aurore DalleÂ > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley,Â > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Aug. 5, 2020

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by tbrunz

Hi Offray, I think you're addressing many of the same concerns as I am, with more of a web/browser orientation perhaps... Which is good. Pharo can make nice, interactive web sites as well as nice, interactive documents, can it not? > I think that we still can make a compelling case for wider audiences > about Pharo and making it more visible. I agree! What do the 'wider audiences' need? What will attract their attention? Being visible is necessary, but is it sufficient? How can we make them want to learn this new tool? (Everyone is so strained for time, and attention is hard to come by these days...) > agility and resilience are not properties of the > overcomplicated web of today So, so true... > .. making suggestions and helping us to improve the software > engineering parts behind such problems/projects, I am also interested in contributing to that. Better tools & methods for solving the problems, better documentation to further understanding and engagement, and better ways for users to employ the results. > I greatly appreciate the experience and teachings of this community. As do I. Cheers! -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 5, 2020

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by tbrunz

> > 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... 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. 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... 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? -t > > S. > > > > > -t > > > > > >> I would put it in class comment. > >> > >> We are about to release a nicer rendering of comments. > >> > >> S. > >> > >>> On 4 Aug 2020, at 06:46, tbrunz wrote: > >>> > >>> I wrote a "theory of operation" document for my app, > >>> https://github.com/tbrunz/logic-puzzle > >>> > >>> But then I realized, "Where do I put it??" > >>> > >>> I thought of a few possibilities: > >>> > >>> * Commit it to the git repo, but then it wouldn't be easy to access > from > >>> Pharo, > >>> * Add it to a top-level Pharo class comment, > >>> * Make it into a string in Pharo, put it in a method in a class. > >>> > >>> What's the standard practice for "attaching" non-code documents to > Pharo > >>> applications? > >>> > >>> -t > >>> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 5, 2020

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by StÃ©phane Ducasse

> 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. S. > > -t > > >> I would put it in class comment. >> >> We are about to release a nicer rendering of comments. >> >> S. >> >>> On 4 Aug 2020, at 06:46, tbrunz <wild.ideas@> wrote: >>> >>> I wrote a "theory of operation" document for my app, >>> https://github.com/tbrunz/logic-puzzle >>> >>> But then I realized, "Where do I put it??" >>> >>> I thought of a few possibilities: >>> >>> * Commit it to the git repo, but then it wouldn't be easy to access from >>> Pharo, >>> * Add it to a top-level Pharo class comment, >>> * Make it into a string in Pharo, put it in a method in a class. >>> >>> What's the standard practice for "attaching" non-code documents to Pharo >>> applications? >>> >>> -t >>> >> > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 5, 2020

Re: [Pharo-users] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding while running Elegant Code image conversion example

by StÃ©phane Ducasse

offray could you add your pictures to the bug entry https://github.com/pharo-project/pharo/issues/7043 S. > On 5 Aug 2020, at 07:53, Tomohiro Oda <tomohiro.tomo.oda(a)gmail.com> wrote: > > Offray, > > I tried it myself and found that the code works on some jpg pics and > does not work on some other pics. > For my case, using PluginBasedJPEGReadWriter instead of JPEGReadWriter > solved the problem. > > Best Regards, > --- > tomo > > 2020å¹´8æ5æ¥(æ°´) 2:43 Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com>: >> >> Thanks Tomo, >> >> I tried your proposal, but now I get: "Error: marker C2 cannot be >> handled" and still the exportation is not working. >> >> Cheers, >> >> Offray >> >> On 4/08/20 2:04 a. m., Tomohiro Oda wrote: >>> Offray, >>> >>> Apparently, readStreamDo: should be binaryReadStreamDo: and >>> writeStreamDo: should be binaryWriteStreamDo: . >>> --- >>> tomo >>> >>> 2020å¹´8æ4æ¥(ç«) 15:42 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Thanks for the report I confirm that I can reproduce the problem. >>>> I do not know yet the answer. Now I think strange that we use a characterStream for reading jpeg. >>>> S. >>>> >>>> >>>> On 3 Aug 2020, at 20:41, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>>> >>>> Hi, >>>> >>>> Today I was an introduction to Pharo. As usual, I asked the learner to >>>> taste the environment and syntax by running the examples in excellent >>>> Sven's Elegant Code[1] (BTW, can I translate snips of it to Spanish?). >>>> When she was adapting the example 6 about converting JPGs to PNGs, we >>>> get the error reported in this mail's subject. I tried running her >>>> example in my machine with her images and with my own and still I got >>>> the same error. What are we missing? >>>> >>>> [1] https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0 >>>> >>>> We are using Pharo 8.x on Manjaro Gnu/Linux 64 bits. >>>> >>>> Thanks, >>>> >>>> Offray >>>> >>>> >>>> >>>> >>>> -------------------------------------------- >>>> StÃ©phane Ducasse >>>> http://stephane.ducasse.free.fr / http://www.pharo.org >>>> 03 59 35 87 52 >>>> Assistant: Aurore Dalle >>>> FAX 03 59 57 78 50 >>>> TEL 03 59 35 86 16 >>>> S. Ducasse - Inria >>>> 40, avenue Halley, >>>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>>> Villeneuve d'Ascq 59650 >>>> France >>>> >> > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 5, 2020