Hi!
I have written a help to use Git in Pharo. Execute the following: Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load. It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help One some point, I will propose an inclusion in the base image. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
## 1. Help in general: Some ideas — this is food for thought for moving forward, not something that I would expect anyone would do tomorrow: ### Simple-ish: online frontend * have an online frontend for all the help — because the first place most people will look is Google, and in-image help doesn't even have elementary search * use formatting… Pillar, Markdown, RST, AsciiDoc, whatever… for the web frontend it doesn't matter, there are nice outputs for all of them * even for the in-image help having some formatting markers might be better than nothing ### Complex-ish * improving in-image help… Offray is/was working on Jupyter (https://try.jupyter.org/) style notebooks. That sounds like a good replacement. * have at least some basic formatting… some time ago there was in-image Pillar editor using GT, so it's doable. ## 2. Comments for the git help (I've just skimmed through it briefly) My impression is that it doesn't really describe git in Pharo, which is what we are pushing for… it is recommanded to tick the checkbox "Initialize this repository with a README". This will ease the initialization of the repository (you will be able to immediately clone your repo). GitHub is lying, you can clone it regardless Open the Monticello browser, accessible from the World menu. Add a filetree:// repository This is not really describing using Git in Pharo… with filetree you could use git forever. You now need to commit and push. These two operations have to be externally to Pharo. Only if you use filetree, because filetree doesn't know about git
Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo. - Identifying difference between versions has to be done externally to Pharo. Actually, this is not that painful. GitKraken offers a nice user interface. Not true for GitFileTree To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective. The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. So my point is: if we want to provide help for people, we should push them in the correct direction… that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives. Peter On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <[hidden email]> wrote: Hi! |
Hi Peter
indeed Alex is not aware that we are actively working on a better integration with a distributed VCS (with for the moment git as target). But the solution should be nicely available. Stef Le 8/5/16 à 17:08, Peter Uhnák a écrit : > > ## 2. Comments for the git help (I've just skimmed through it briefly) > > My impression is that it doesn't really describe git in Pharo, which > is what we are pushing for… |
In reply to this post by Peter Uhnak
> So my point is: if we want to provide help for people, we should push > them in the correct direction… that is towards git IN pharo. > If we push them to not actually use git in Pharo, then we will push > them away from our objectives. +1 I do not want pharo to be bound to use external merging tools. Stef |
In reply to this post by Peter Uhnak
Hi Peter!
Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-) > The in-image help sucks hard… monospaced walls of text, no formatting, no styling, no images, and zero discoverability. > > Some ideas — this is food for thought for moving forward, not something that I would expect anyone would do tomorrow: I agree with you. But there are several use cases here. Any professional application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example). > ### Simple-ish: online fronted > ... > ### Complex-ish > … Sure, would be great :-) > ## 2. Comments for the git help (I've just skimmed through it briefly) > > My impression is that it doesn't really describe git in Pharo, which is what we are pushing for… > > > it is recommanded to tick the checkbox "Initialize this repository with a README". > This will ease the initialization of the repository (you will be able to immediately clone your repo). > > GitHub is lying, you can clone it regardless Well.. I am okay living with this lie :-) > - From Pharo you can _only_ save and load your code frmo the harddisk (see the chapter Alternative for more options) > > Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo. Does remote git repo works well on OS X? And more importantly, merging is something that we are still miles away to do it within Pharo, sadly. > To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective. The objective is to have a single place with that information, accessible without at looking at videos and browsing mailing list archive :-) > The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. Yes, that would be great. > So my point is: if we want to provide help for people, we should push them in the correct direction… that is towards git IN pharo. > If we push them to not actually use git in Pharo, then we will push them away from our objectives. Yes, but that will take years before getting there. And I need to use it now… and this help actually does help me (creating a baseline and configuration are unfortunately still serious challenges). In any case, I will use this Help for me, and will not try to push it. Thanks for having a look at it :-) Cheers, Alexandre > > > > On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <[hidden email]> wrote: > Hi! > > I have written a help to use Git in Pharo. Execute the following: > > Metacello new > baseline: 'GitHelp'; > repository: 'github://bergel/Git-Help:master'; > load. > > It will load a Help topic, available on the Help Browser. > If you wish to contribute: > https://github.com/bergel/Git-Help > > One some point, I will propose an inclusion in the base image. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by stepharo
> indeed Alex is not aware that we are actively working on a better integration with a distributed VCS (with for the moment git as target).
> > But the solution should be nicely available. Anything to try ? Alexandre > > > Le 8/5/16 à 17:08, Peter Uhnák a écrit : >> >> ## 2. Comments for the git help (I've just skimmed through it briefly) >> >> My impression is that it doesn't really describe git in Pharo, which is what we are pushing for… > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by stepharo
>> So my point is: if we want to provide help for people, we should push them in the correct direction… that is towards git IN pharo.
>> If we push them to not actually use git in Pharo, then we will push them away from our objectives. > +1 > > I do not want pharo to be bound to use external merging tools. Me neither. But the competition is really though. Anyway, let’s see what the future will bring :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-) I understand the purpose, which is very important. I only question the content, whether we really want to push users in that direction. I agree with you. But there are several use cases here. Any professional application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example). Unfortunately I find the builtin-help very unpractical… I'd much rather look at actual code samples. In fact on Pharo Days this year Andrei did experiments with GTSpotter, and none of the participants (me included) looked at the builtin help, everyone was looking just at real samples of code. Most people do not seek understanding, only solving their problem… which is not bad of itself… but we should address both. Does remote git repo works well on OS X? And more importantly, merging is something that we are still miles away to do it within Pharo, sadly. I don't see why it wouldn't. There were problems on Windows, but that's related to ProcessWrapper, not gitfiletree. OSSubprocess has maybe fixed that on Windows? Merging will be, unfortunately still a challenge, although GitFileTree-Merger works surprisingly well. But if we push for in-image git, then tools will slowly emerge (as they already do)… if we push users out of the image, then there would be much less incentive. Besides anything that's available to you with FileTree, you also have available with GitFileTree (but not vice versa). The objective is to have a single place with that information, accessible without at looking at videos and browsing mailing list archive :-) That's why I mentioned centralized front-end for the help with nice search, formatting and everything. Currently achieving this in browser is trivial compared to the work necessary to do it in-image… > The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. Yes, that would be great. It _is_. Present tense. > So my point is: if we want to provide help for people, we should push them in the correct direction… that is towards git IN pharo.
I've been using gitfiletree for more then year and a half without any (major) issues on gitfiletree side. It may take years to have a really good integration, but even now it's much better than just plain filetree, because you are not losing in-image diffs and history, and because you don't need to use an external tool. In any case, I will use this Help for me, and will not try to push it. Btw. if you need a place to store your snippets, take a look at Torsten's QuickAccess https://www.youtube.com/watch?v=j-dTp6i_P3s . I'm using it a lot and it's super cool for snippets. :) On Sun, May 8, 2016 at 6:31 PM, Alexandre Bergel <[hidden email]> wrote: >> So my point is: if we want to provide help for people, we should push them in the correct direction… that is towards git IN pharo. |
In reply to this post by Peter Uhnak
On Sun, May 08, 2016 at 05:08:37PM +0200, Peter Uhnák wrote:
> ## 1. Help in general: > > The in-image help sucks hard… monospaced walls of text, no formatting, no > styling, no images, and zero discoverability. > > Some ideas — this is food for thought for moving forward, not something that I > would expect anyone would do tomorrow: > > ### Simple-ish: online frontend > > * have an online frontend for all the help — because the first place most > people will look is Google, and in-image help doesn't even have elementary > search > * use formatting… Pillar, Markdown, RST, AsciiDoc, whatever… for the web > frontend it doesn't matter, there are nice outputs for all of them > * even for the in-image help having some formatting markers might be better > than nothing > > ### Complex-ish > > * improving in-image help… Offray is/was working on Jupyter (https:// > try.jupyter.org/) style notebooks. That sounds like a good replacement. > * have at least some basic formatting… some time ago there was in-image Pillar > editor using GT, so it's doable. +1 How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web, and a wiki that lowers the cost of contributing? The wiki would also act as a place where the documentation can evolve until it is considered stable enough to include in the image. It can also have links to other blogs, etc. that may not be appropriate for in-image documentation Speaking of wikis, what is the status of the collaborActive book? It usually appears near the top of my google searches, but appears to be quite out of date. I'd be happy to update it a bit while still in the learning phase of Pharo if someone can provide credentials. Cheers, Alistair |
How about WebDoc (or similar) serving up the API with class comments to Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). I don't think that any web interface can compete with that (unless it's powered by Pharo itself). In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples. The wiki would also act as a place where the documentation can evolve For this we have books imho. Simple documentation should be added to image. also have links to other blogs, etc. that may not be appropriate for I don't see why not, but it would be better to just copy the content without having to click (depends on the content). |
> On 09 May 2016, at 09:37, Peter Uhnák <[hidden email]> wrote: > > How about WebDoc (or similar) serving up the API with class comments to > make it searchable on the web > > Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. > Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). > I don't think that any web interface can compete with that (unless it's powered by Pharo itself). > > In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples. See http://files.pharo.org/doc/ for WebDoc. I do totally agree with the fact that Pharo is first and foremost an in-image IDE, we should concentrate on that. The web based documentation is mostly relevant for search indexing and newcomers. > The wiki would also act as a place where the documentation can evolve > until it is considered stable enough to include in the image. > > For this we have books imho. Simple documentation should be added to image. > > also have links to other blogs, etc. that may not be appropriate for > in-image documentation > > I don't see why not, but it would be better to just copy the content without having to click (depends on the content). |
Search wise you can use GTSpotter to search help topic, I even added that myself as a plugin to GTSpotter at some point with even the ability to preview help inside GTSpotter. Look wise, sure pharo help isnt the prettiest thing but I would not it say it sucks, it does its job okish, it displays help text. On Mon, May 9, 2016 at 10:45 AM Sven Van Caekenberghe <[hidden email]> wrote:
|
this would be something nice to add :)
yes, but we need something better, in the future. Esteban
|
Thanks for all your replies.
I like having the in-image documentation, and the books are a great resource. However neither the in-image documentation or books encourage collaboration and updates make their way out relatviely slowly. (I'm assuming the Pillar documentation referred to by Dimitris are the books). I still think there is a place for a wiki. For information that can later be moved either in-image or to one of the books. Even just having pointers to the in-image information and relevant sections within the books will make the information more searchable (the in-image tools not withstanding) and will be useful for newcomers. It can also hold documentation about new features that aren't yet in the books or in-image (I made the same mistake in trying to use filtree with git, instead of gitfiletree). I'd still like to contribute to the collaborActive book (http://pharo.gemtalksystems.com/book). Is it possible to get credentials? Thanks! Alistair |
In Pharo you can also load "PharoOnlineHelp" from Catalog Browser.
It was an experiment (already back in Pharo 3) from me to provide a web based help system for Pharo. I updated it to work on Pharo 5 now. Primarily this is Zinc serving some HTTP pages. Tutorials can be written in Markdown with rendering in HTML. Bye T. > Gesendet: Dienstag, 10. Mai 2016 um 08:11 Uhr > Von: "Alistair Grant" <[hidden email]> > An: [hidden email] > Betreff: Re: [Pharo-dev] Online documentation (was: Help on using Git with Pharo) > > Thanks for all your replies. > > I like having the in-image documentation, and the books are a great > resource. However neither the in-image documentation or books encourage > collaboration and updates make their way out relatviely slowly. (I'm > assuming the Pillar documentation referred to by Dimitris are the > books). > > I still think there is a place for a wiki. For information that > can later be moved either in-image or to one of the books. Even just > having pointers to the in-image information and relevant sections within > the books will make the information more searchable (the in-image tools > not withstanding) and will be useful for newcomers. It can also hold > documentation about new features that aren't yet in the books or > in-image (I made the same mistake in trying to use filtree with git, > instead of gitfiletree). > > I'd still like to contribute to the collaborActive book > (http://pharo.gemtalksystems.com/book). Is it possible to get > credentials? > > Thanks! > Alistair > > |
In reply to this post by abergel
Alexandre
I do not understand why you are so negative. May be people are using git from within Pharo. May be your experience was not good. Now Nicolas is working to bring the possibility to publish on gitlike systems inside pharo. I imagine that when it will be ready to try we will know it. Stef Le 8/5/16 à 18:29, Alexandre Bergel a écrit : > Hi Peter! > > Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-) > >> The in-image help sucks hard… monospaced walls of text, no formatting, no styling, no images, and zero discoverability. >> >> Some ideas — this is food for thought for moving forward, not something that I would expect anyone would do tomorrow: > I agree with you. But there are several use cases here. Any professional application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example). > > >> ### Simple-ish: online fronted >> ... >> ### Complex-ish >> … > Sure, would be great :-) > >> ## 2. Comments for the git help (I've just skimmed through it briefly) >> >> My impression is that it doesn't really describe git in Pharo, which is what we are pushing for… >> >> >> it is recommanded to tick the checkbox "Initialize this repository with a README". >> This will ease the initialization of the repository (you will be able to immediately clone your repo). >> >> GitHub is lying, you can clone it regardless > Well.. I am okay living with this lie :-) > >> - From Pharo you can _only_ save and load your code frmo the harddisk (see the chapter Alternative for more options) >> >> Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo. > Does remote git repo works well on OS X? And more importantly, merging is something that we are still miles away to do it within Pharo, sadly. > >> To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective. > The objective is to have a single place with that information, accessible without at looking at videos and browsing mailing list archive :-) > >> The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. > Yes, that would be great. > >> So my point is: if we want to provide help for people, we should push them in the correct direction… that is towards git IN pharo. >> If we push them to not actually use git in Pharo, then we will push them away from our objectives. > Yes, but that will take years before getting there. And I need to use it now… and this help actually does help me (creating a baseline and configuration are unfortunately still serious challenges). > > In any case, I will use this Help for me, and will not try to push it. > Thanks for having a look at it :-) > > Cheers, > Alexandre > > >> >> >> On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <[hidden email]> wrote: >> Hi! >> >> I have written a help to use Git in Pharo. Execute the following: >> >> Metacello new >> baseline: 'GitHelp'; >> repository: 'github://bergel/Git-Help:master'; >> load. >> >> It will load a Help topic, available on the Help Browser. >> If you wish to contribute: >> https://github.com/bergel/Git-Help >> >> One some point, I will propose an inclusion in the base image. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> |
Free forum by Nabble | Edit this page |