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

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

by Tudor Girba

Hi, If Moz2D is installed, the fonts should work fine. Can you please try the installation again? And if it does not work, please let me know if in Settings Browser / Appearance / Bloc / Preferable Sparta renderering backend you see Moz2D or not. Cheers, Doru > On Jun 15, 2018, at 2:31 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi Doru, > > Thanks for the update in Markdown. I will try to bring better Markdown > support in Pharo by developing my ideas on a Playground for Markdown > with syntax highlighting, image preview and so on and maybe I can help > in incorporating them in GT Documenter on Pharo 7. > > I can confirm that fonts didn't work on Manjaro on 64 bits installation > running Pharo 64b previously, but maybe in Pharo 7 installation will be > smoother, including font installation via Moz2D integration (nix package > manager has been a real asset in our workshops in multiple Unix > environments, including Mac and several Gnu/Linux flavors, so maybe it > can help with Moz2D engine and fonts integration). > > Cheers, > > Offray > > > On 15/06/18 00:56, Tudor Girba wrote: >> Hi, >> >> I am happy you like it. >> >> Fonts should work with a Pharo 64b installation on Linux, including Manjaro. Can you confirm that you use a Pharo 64bit and that it does not work? If yes, can you describe how you are installing Pharo and GToolkit? >> >> Markdown is certainly interesting, but it is not our focus at this point. We are building on top of Pillar. There are several reasons for it, two of them being: >> 1. To build the experience we want to, we need deep control over the markup language and Pillar provides that in Pharo. >> 2. Pillar is the de facto documentation markup used in Pharo, and our primary focus is to support new kinds of development workflows in this environment, including handling documentation. >> >> GT 2nd generation will indeed not be part of Pharo 7, but will be loadable in it. >> >> Cheers, >> Doru >> >> >> >>> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>> >>> Cool! I hope to see how this could be integrated in Grafoscopio once Documenter is better integrated with Pharo, for example addressing the font issues already reported in the mailing list on Manjaro Linux (64 bits) and in the thread at [1] and also the Markdown integration possibilities (which are never answered). >>> [1] https://twitter.com/feenkcom/status/996310432225820672 >>> >>> I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to use it in a more confident day to day fashion. >>> >>> Keep the interesting work. >>> >>> Cheers, >>> >>> Offray >>> >>> On 13/06/18 15:57, Tudor Girba wrote: >>>> 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." >>>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Being happy is a matter of choice." >> >> >> >> >> >> > > > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

June 16, 2018

Re: [Pharo-users] Tonel Fileout

by Ben Coman

Le 16/06/2018 Ã 10:43, Ben Coman a Ã©crit : > How can a fileout/filein be done using Tonel format? > In the first case as a script? > and secondly as a possible menu option for Pharo? > > This is to facilitate transfer of student coding exercises for Exercism. > http://exercism.io/languages/pharo/launch > > Could Tonel handle a full package export in one file? > On 16 June 2018 at 17:13, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi Ben, > > I am not sure, but the purpose of Tonel is to propose a file > representation of "one class=one file". > Sure thats how Tonel came about, and its how we mostly use it, but is this an inherent limitation? Each method is prefixed with its class, so from my 100ft viewpoint it seems feasible to transport a whole package in one Tonel file. Why not using Fileout st files to transfer the code? > The same question might be asked why Iceberg didn't just use a Fileout at class level. The Tonel format is more readable, especially minus the scattering of exclamation marks. I also meant to ask, what methods are used to file-in a Tonel file ? Or more the point, what method process a string in Tonel format that has been downloaded from a website? Actually, hunting around a bit I found.... TonelParserTest >> testMethodDefList shows that... ((TonelParser on: tonelString readStream) perform: #methodDefList) returns an array of MCMethodDefinitions that respond to #load with... MCMethodDefinition >> load self actualClass compile: source classified: category withStamp: timeStamp notifying: nil And... TonelParserTest >> testTypeDef shows that ((TonelParser on: tonelString readStream) perform: #typeDef) returns a MCClassDefinition that also responds to #load with... MCClassDefinition >> load self createClass So as an experiment I deleted MCMockClassD, then in playground evaluated... tonelString := (ZnEasy get: ' https://raw.githubusercontent.com/pharo-project/pharo/development/src/Monti…') contents. parser := (TonelParser on: tonelString readStream). classDef := parser perform: #typeDef. methodDefs := parser perform: #methodDefList. classDef load. methodDefs do: [ :md | md load ]. and super cool... MCMockClassD>>one was restored. So is that the correct way to use it? cheers -ben

June 16, 2018

Re: [Pharo-users] [Pharo-dev] @pharoproject: > 2000 followers

by Tudor Girba

Great news! Doru > On Jun 15, 2018, at 11:11 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > @pharoproject on twitter now has >2000 followers: https://twitter.com/pharoproject -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

June 16, 2018

Re: [Pharo-users] Tonel Fileout

by Hilaire

Hi Ben, I am not sure, but the purpose of Tonel is to propose a file representation of "one class=one file". In that case, does exporting a whole package in one file with the Tonel notation exist or make sense? Why not using Fileout st files to transfer the code? (RPackage named: 'DrGeoII-Core') fileOut. 'DrGeoII-Core.st' asFileReference fileIn Hilaire Le 16/06/2018 Ã 10:43, Ben Coman a Ã©critÂ : > How can a fileout/filein be done using Tonel format? > In the first case as a script? > and secondly as a possible menu option for Pharo? > > This is to facilitate transfer of student coding exercises for Exercism. > http://exercism.io/languages/pharo/launch > > Could Tonel handle a full package export in one file? > -- Dr. Geo http://drgeo.eu

June 16, 2018

Tonel Fileout

by Ben Coman

How can a fileout/filein be done using Tonel format? In the first case as a script? and secondly as a possible menu option for Pharo? This is to facilitate transfer of student coding exercises for Exercism. http://exercism.io/languages/pharo/launch Could Tonel handle a full package export in one file? cheers -ben

June 16, 2018

Re: [Pharo-users] Lost in stream

by Hilaire

Sometime you just need a good sleep, which I was fortunate to have. My newer code append contents to existing file, so it lead to corrupted files at the end. Ensuring it is deleted first solved the problem: (locationÂ asFileReference / filename) ensureDelete binaryWriteStreamDo: [ :fileStream | Â Â Â Â Â fileStream nextPutAll: stream contents] There is still the issue of XML entity I described in an previous email, the impact is minor for Dr. Geo though. Do other have issues with that? Hilaire Le 15/06/2018 Ã 18:31, Hilaire a Ã©critÂ : > This fromer code to save file (xml or PNG file): > > " |streamOnDisk| > Â Â Â [streamOnDisk := MultiByteFileStream forceNewFileNamed: (self > absolutePath: filename). > Â Â Â streamOnDisk nextPutAll: stream contents] ensure: > Â Â Â Â Â Â [streamOnDisk close]" > > and the newer one: > > Â Â Â (locationÂ asFileReference / filename) binaryWriteStreamDo: [ > :fileStream | > Â Â Â Â Â Â fileStream nextPutAll: stream contents] > > The new one produce both wrong XML file and PNG file. The file looks > short cuted at the end. -- Dr. Geo http://drgeo.eu

June 16, 2018

Re: "News" section of the website down

by orsayman

Yes, it's back. Thanks ! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 15, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Tim Mackinnon

Phew - I can confirm that (unsurprisingly I guess) - just committing in Iceberg (without ticking - push changes to origin/master) does then let you easily overlay the same checked out project (typically ./iceberg/ProjectName) in a tool like VSCode or IntelliJ where you can then also commit further changes to files that Iceberg is ignoring (essentially everything not in the src directory - typically candidates would be your Readme.md file and possibly a ./scripts or ./assets directory). In that other tool you can then issue a push which will then atomically push all commits to a pipeline. It can be a little more tricky to understand what the pipeline is building - in Gitlab it will show you the comment of the most recent commit in the pipeline, however if you then click on the branch the pipeline is running on, you will get a list of commits and can see all the commits that are between the running pipeline and the previously run pipeline. For many of you - this might be pleadingly obvious - but when you have a different workflow mindset in your head, it might be trickier to spot this subtlety. Tim p.s. Thanks for all the useful debate in this thread. I should add that when I wrote âIâll shut upâ - a meant more that I felt the conversation was going in a cycle and repeating itself, not that I was offended or frustrated. I can probably live with the above nuance for my desire for atomic commits. p.p.s It hadnât occurred to me that the most common use case where people will hit a similar problem to me - is that Readme.md file. Definitely that is one where it should possibly automatically added to the index, or catered for - as it is really just a text file right? > On 15 Jun 2018, at 18:26, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > >> On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >>> On 15 Jun 2018, at 10:29, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> >>> >>> In many parts of the dev world - every commit should be shippable, meaning atomic - particularly with the use of CI systems (Travis, Gitlab etc) that build on every commit. >> >> but then, you mean every *push* should be shippable :) >> thatâs something I agree :) > > The way we run projects - pushing to master is forbidden. You push your work to a feature specific branch, a CI server runs all the tests in the branch every push. We create pull requests from the github project page, people review them and when the tests are green and reviewers approve, we perform the merge on github. > > Never touch master (or whatever branch you pick for main trunk) outside of github. Always perform new work in new branch. >

June 15, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Tim Mackinnon

Tod/Norbert - I wonât shy away from answering your comments on this - but if its ok - lets move that conversation to a new thread. I donât want to distract away from how one actually does some form of atomic checkin (and Iâm talking a small one - one Smalltalk class, one associated text file). I earlier tried doing a change on a class - committing, but not pushing and then switching to IntelliJ to then commit and push my config file change - and it didnât seem to work - which surprised me, so Iâm gong to redo my test again with the the latest Iceberg 1.1 in a new image (and also make sure my IntelliJ is attached to the same local repo). This seems like the closest root to how I would like to work (albeit a slightly bit more complicated than I would like, but certainly doable). Tim > On 15 Jun 2018, at 18:26, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > >> On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >>> On 15 Jun 2018, at 10:29, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> >>> >>> In many parts of the dev world - every commit should be shippable, meaning atomic - particularly with the use of CI systems (Travis, Gitlab etc) that build on every commit. >> >> but then, you mean every *push* should be shippable :) >> thatâs something I agree :) > > The way we run projects - pushing to master is forbidden. You push your work to a feature specific branch, a CI server runs all the tests in the branch every push. We create pull requests from the github project page, people review them and when the tests are green and reviewers approve, we perform the merge on github. > > Never touch master (or whatever branch you pick for main trunk) outside of github. Always perform new work in new branch. >

June 15, 2018

Re: [Pharo-users] How to contribute to Pharo Launcher?

by Tim Mackinnon

Hi Christophe - you are right, I did contribute many years ago (I found the Mcz field on my disk when I just checked now) - but Iâll be darned If I can remember how it works (I have to confess, I never really got on with Metacello and slices). Do I simply take my latest .mcz file in my local directory and somehow apply it to the sthub repo (sorry if this is obvious to you - but Iâve plain forgotten how its done). It would be good to get it into GitHub - it certainly seems to work pretty well now for most things, and it makes contributing so much easier. Tim > On 15 Jun 2018, at 08:14, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Tim, > >> Le 14 juin 2018 Ã 18:48, Tim Mackinnon <tim(a)testit.works> a Ã©crit : >> >> Is PharoLauncher using git - there is a note saying the StHub repo is about to be moved? >> >> I ask as I wanted to contribute a simple change that shows the modified date of the images and lets you sort by that (I sometimes forget which was the latest image I was using and have a few old ones kicking around). > > > Until now, I preferred to stay on StHub mainly because Iceberg was not ready to work smoothly with. I did not wanted to get extra-difficulties to work on Pharo Launcher (merge problems, etc). > That said, Iceberg has now moved a lot in the right direction and I think we could start to use git for Pharo Launcher development. > I will release a ne version of PharoLauncher soon and then, I think I will move PharoLauncher on github and use Cargo to manage it. > > For your contribution, it is welcomed (in fact, it was planned to be added but you were faster). Feel free to commit it directly to the SH repository, I will then take a look at it. It looks like you already can commit: http://smalltalkhub.com/#!/~Pharo/PharoLauncher/contributors. > > Thanks Tim. > > Regards, > Christophe

June 15, 2018