July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 7 streams API

by Sven Van Caekenberghe

> On 24 Jun 2018, at 03:08, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 24 June 2018 at 00:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Peter, > > > On 23 Jun 2018, at 15:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). > > > > So a statement like this > > > > aFile writeStreamDo: [ :stream | > > stream lineEndConvention: #lf. > > stream << '...' > > ]. > > > > has to be written like so > > > > aFile writeStreamDo: [ :rawStream | |stream| > > stream := (ZnNewLineWriterStream on: rawStream) forLf. > > stream << '...' > > ]. > > > > which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. > > > > Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. > > > > aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | > > stream << '...' > > ] > > > > To separate the composition from the usage? > > > > Thanks, > > Peter > > The goals of the 'new' (they have existed for quite a while) streams is to go from single big complex do all classes and replace that with a composition of much simpler single purpose classes. Another goal is to reduce the API so that it becomes easier to create new stream classes. Of course, a consequence is that you need composition to get the functionality you want. But I think you understand the tradeoff. > > If the mixing of configuration/setup with writing/reading bothers you, then I would suggest using two methods. One that does only the writing/reading assuming a limited API, and another that does the configuration/setup, using composition. > > Note that the streams that you get already are a composition (most often a BinaryFileStream wrapped in a Buffered stream wrapped in a Encoding/Decoding stream). EOL translation is not a standard part of that. But there is quite some system code that does uses EOL translation. > > There may be performance implications for streams opened frequently, but perhaps something like this would be useful...?? > aFile writeStreamDo: [ :stream | > stream becomeWrappedBy: ( ZnNewLineWriterStream new forLf). > stream << '...' > > cheers -ben #becomeWrappedBy: would (indeed) have to use #become[Forward:] for little gain in reducing code density while adding complexity, IMHO.

July 2, 2018

Re: [Pharo-users] [Moose-dev] Re: [ann] gt documenter

by Sven Van Caekenberghe

> On 17 Jun 2018, at 15:09, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Tudor. > > This is super impressive. +10 > What's next? Do you plan to implement IDE for writing documents, navigation, refactorings? (senders, renames should find all places in documents) > > 2018-06-13 21:57 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are happy to announce a new leap of GToolkit Documenter, the tool for manipulating live documents directly in the development environment: > https://github.com/feenkcom/gtoolkit-documenter > > Documenter is part of the second generation GToolkit project, it is based on Bloc and works with the latest Pillar. It is mainly developed by Juraj Kubelka. > > Attached you can see a preview of how documents look like: > > <gt-documenter.png> > > At its core it offers a live editor for manipulating Pillar documents. The interaction happens seamlessly directly in the text editor, and it can be combined with different types of previews to serve several classes of use cases: > â¢ code documentation > â¢ tutorials > â¢ interactive data notebook > > > Code documentation > ---- > Documenter complements the GToolkit Examples engine to redefine code documentation. When practicing example-driven development, examples get written as part of the typical development. Once examples exist, they can be quickly put together in a document to form documentation. For example, the linked picture shows the comment of a class containing a visual explanation: > https://twitter.com/feenkcom/status/973899862482866176 > > You can see a live example of documentation by inspecting the following snippet: > GtDocumenter editorForText: BrToggleExamples comment. > > > Tutorials: > ---- > Documenter offers a new experience of writing tutorials for Pharo by enabling the creation and embedding of Epicea change sessions directly in the document. For example, take a look at the following animation: > https://twitter.com/feenkcom/status/999975333972541440 > > The document shows a method on top, and a change preview at the bottom showing both the code and the associated diff to the state from the image. Applying the change updates both the change view (no more diff), and method preview. This speeds up significantly the process of going through a tutorial. Furthermore, given that now the document shows the diff to the current image, the reader can safely explore alternative scenario and come back to the tutorial at any time without losing the overview. > > The size of the preview can also be adjusted live: > https://twitter.com/feenkcom/status/1001152789874167808 > https://twitter.com/feenkcom/status/1001407762285375490 > > You can see a live tutorial by inspecting: > IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillarâ. > > > Interactive data notebook: > ---- > A Documenter document can also be used as an interactive notebook. Internally it essentially acts as a playground: > â¢ it supports defining variables in code snippets, and > â¢ the execution of code shows an embedded inspector. > > For example: > https://twitter.com/feenkcom/status/996310432225820672 > https://twitter.com/feenkcom/status/1002851190475026432 > > An example, can be seen by inspecting: > IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'gtoolkit' / 'gtoolkit.pillar'. > > > As always, please do let us know what you think. > > Enjoy, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "If you can't say why something is relevant, > it probably isn't." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

July 2, 2018

Re: [Pharo-users] How to get changes applied to Pharo website?

by Esteban Lorenzano

Hi, I think the easiest way is to add an issue and submit a PR, yes (even if this is not a code change) cheers! Esteban > On 2 Jul 2018, at 13:33, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - what is the easiest way to propose changes to the Pharo website? > > Iâd like to get an id put on the <h2>Command Line</h2> section, so that we can easily link to this part of the website to send people to instructions on using the terminal? > > E.g http://pharo.org/download#CommandLine <http://pharo.org/download#CommandLine> > > Do I raise a Fogbugz? > > Tim

July 2, 2018

How to get changes applied to Pharo website?

by Tim Mackinnon

Hi - what is the easiest way to propose changes to the Pharo website? Iâd like to get an id put on the <h2>Command Line</h2> section, so that we can easily link to this part of the website to send people to instructions on using the terminal? E.g http://pharo.org/download#CommandLine <http://pharo.org/download#CommandLine> Do I raise a Fogbugz? Tim

July 2, 2018

Re: [Pharo-users] What's the status of Pharo exercism?

by Ben Coman

> On 29 Jun 2018, at 23:32, Ben Coman <btc(a)openinworld.com> wrote: > > Per (https://github.com/exercism/meta/issues/91) > it looks like the syntax highlighter is "prism" (https://prismjs.com/) > I added ".st" for Pharo... (https://github.com/exercism/m > eta/issues/90#issuecomment-399412215). > > It briefly crossed my mind to wonder if using ".st" for both traditional > fileout format and tonel format might cause complications, > but that might be jumping at shadows. Ultimately the both comprise > Smalltalk syntax. > > cheers -ben > > On 30 June 2018 at 01:55, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi Ben - it looks completely do-able. >> >> Just submitted my hello world for python - and it wasnât anything >> particularly special. I thought your suggestion of using Tonel is perfect - >> Iâm just not sure how well the exercism site will render tonel format >> (ideally with correct colour coding). >> >> Iâve noticed there are lots of Textmate themes for Smalltalk floating >> around (and indeed I took one and put it on my iPad for a text app whoâs >> name Iâve forgotten and it seemed to render tonal fine). So if exercism >> uses that - then it really shouldnât be a ton of work to make the >> submit/pull calls like you suggested? It seems that exercism is just >> providing conversations and a push pull mechanism - so really its git with >> training wheels? Or have I missed something? >> >> Tim >> >> On 29 Jun 2018, at 17:14, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On 29 June 2018 at 22:53, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> Presumably someone is working on Pharo Exercism (did I notice Ben or >>> Hilaire asking about the tonel format for it?) >>> >>> Is it possible for someone to put a comment in the repo for it - so we >>> can coordinate effort? Iâm assuming that someone can at least get hello >>> world working as an example? >>> >>> It would also be handy if someone who understands how it works, can give >>> a quick explanation here - as I would offer to suggest it as something for >>> the next UK Smalltalk gathering next month. Iâm assuming the cli submits >>> files to some travis runner and you get results back - and we just have to >>> fill something in that will interpret those files and launch a command line >>> pharo to get the results (presumably handling walkbacks in a way that the >>> results get fed back). And then Iâm guess we have a pharo add-in that would >>> let you do this from the image some way too? >>> >>> Tim >>> >> >> I don't know much or even how I ended up tuning in on it - but of several >> of these sorts of initiatives I've heard about, Exercism looks like a good >> one. >> I haven't put any thought into exercises, but have been thinking about >> infrastructure. >> >> Here is some discussion about making a code exporter to be able to use >> the command line tool to interact with the server. >> https://github.com/exercism/pharo/issues/6#issuecomment-398346884 >> >> I've been looking at how the command line tool communicates with the >> server >> to determine how hard it would be too hard to write a Pharo direct >> interface to their server. >> I wasn't planning to share my experiments yet, but since it may be a >> while before I get a chance to extend it further, >> perhaps it interests someone... >> https://github.com/bencoman/pharogui-exercism >> >> On 30 June 2018 at 06:38, Tim Mackinnon <tim(a)testit.works> wrote: > Nice one Ben - I think a few quick iterations could get something out the > door and then we can refine it and make it really cool! > Btw, for on lookers, I'm more and more liking what I see in Exercism, with templates to help generate problem descriptions and test data for exercises. For example... * https://github.com/exercism/problem-specifications/blob/master/exercises/do… * https://github.com/exercism/problem-specifications/blob/master/exercises/do… * https://github.com/exercism/docs/blob/master/language-tracks/exercises/anat… cheers -ben

July 1, 2018

Re: [Pharo-users] Smalltalk Programming Competition

by horrido

So far, we've raised CA$2,400 from 18 generous contributors. Not bad for the first two weeks of the GoFundMe campaign: https://www.gofundme.com/smalltalk-programming-competition I've lowered the funding goal to $25,000. So we're now about 10% of the way to the target. Meanwhile, I've been busy preparing for the competition. Here is the competition website, currently rigged as a demo: http://smalltalkrenaissance.pythonanywhere.com/JRMPC/default/index When it goes live, the proper sponsors will be displayed, and the database will be scrubbed clean. I've also design T-shirts (swag) for the competition. Here's the main design: <http://forum.world.st/file/t128560/T-shirt-x.png> Here's the alternate design: <http://forum.world.st/file/t128560/Hot-Air-Balloon-x.png> Everything is lining up, ready to go. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 1, 2018

Re: [Pharo-users] do-it or inspect-it in the spotter search bar?

by Sven Van Caekenberghe

> On 1 Jul 2018, at 01:28, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > > I was feeling lazy was wondered if it would be possible to hit Cmd-D or Cmd-I in the spotter input field rather than opening a playground and typing something in then hitting it. E.g. > > > 1 + 1 Cmd-I > > would open an inspector on the number 2 > > > After looking at GTSpotter>>#spotterFor... methods I couldn't figure out how to make it happen in the half hour I had to spend on it. > > > I recognize opening the playground is Cmd-O Cmd-W but I just open the spotter ~50x as often as a new playground so the muscle memory isn't there. If I could do quick one-liners in the spotter then the playground would get opened even less often. In Pharo 7 you can actually use Spotter for calculations: Cmd-Enter 1 + 2 gives you #Calculator 3 Even 42 factorial works. It does not seem to work for general evaluation though ... The tools that we had before Spotter did actually allow that.

July 1, 2018

Re: [Pharo-users] do-it or inspect-it in the spotter search bar?

by Richard Sargent

Paul, That's an excellent suggestion. Wherever one can type text, one should be able to do text operations on it. And wherever one can type code, one should be able to do code operations on it. (And, for completeness, one should be able to do a subset of each wherever text and code are displayed.) On Sat, Jun 30, 2018, 16:28 PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > I was feeling lazy was wondered if it would be possible to hit Cmd-D or > Cmd-I in the spotter input field rather than opening a playground and > typing something in then hitting it. E.g. > > > 1 + 1 Cmd-I > > would open an inspector on the number 2 > > > After looking at GTSpotter>>#spotterFor... methods I couldn't figure out > how to make it happen in the half hour I had to spend on it. > > > I recognize opening the playground is Cmd-O Cmd-W but I just open the > spotter ~50x as often as a new playground so the muscle memory isn't > there. If I could do quick one-liners in the spotter then the playground > would get opened even less often. > > > > > > > > > > >

July 1, 2018