- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help on using Git with Pharo

by Alexandre Bergel

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 <alexandre.bergel(a)me.com> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 8, 2016

Re: [Pharo-dev] Help on using Git with Pharo

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. Stef

May 8, 2016

ProcessAlready Terminated

by Alexandre Bergel

Hi (Mariano)! I have successfully used OSSubprocess. After having saved the image and started again, I get an error: Any idea why? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 8, 2016

Re: [Pharo-dev] Help on using Git with Pharo

by stepharo

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â¦

May 8, 2016

Improving FileSystem. Storgae API

by stepharo

After discussion with me and esteban Valentin proposed the following: https://pharo.fogbugz.com/f/cases/18157/ModificationTime-creationTime-size the idea is to improve getter names and not setters name for getters. I reviewed it and it looks ok for me Stef

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 08-05-16 17:19, Peter UhnÃ¡k wrote: > We should have metrics for thisâ¦ otherwise seeing what's the actual > impact is a guesswork. > Most ValueHolders will have at least (and usually) one subscriber â > the adapter Most have 0 1741 NewValueHolders, 911 with 0, 801 with 1 NewValueHolder allInstances select: [ :each | (each instVarNamed: #announcer) numberOfSubscriptions = 1 ] Stephan

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 08-05-16 17:13, Peter UhnÃ¡k wrote: > Can you give me an example of how would you use it with LabelModel? Not a good one. I've seen it used as a droptarget for a directory, where the corresponding textfield provided the file name. Stephan

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Peter UhnÃ¡k

On Sun, May 8, 2016 at 4:54 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 08-05-16 09:59, stepharo wrote: > >> > We did an experience by trying to remove the valueHolder is > >> > ButtonPresenter but it led to refresh problem when we want to update > the > widget. > > If we want to have such fine-grained change propagation with a > NewValueHolder for each widgetproperty, we need a much more lightweight > announcement proces. > NewValueHolder initializes a boolean lock and an Announcer. The announcer > initializes a SubscriptionRegistry. The subscriptionregistry initializes a > Semaphore and an IdentitySet. An identityset initializes with a tally and a > size of 5. If we know most valueholders never need to propagate a change, > and most of the others only to one subscriber, we should introduce some > null/one objects. We should have metrics for thisâ¦ otherwise seeing what's the actual impact is a guesswork. Most ValueHolders will have at least (and usually) one subscriber â the adapter. But a lightweight announcer might be better. Or use a different mechanism, although I have no idea what kind. > Alternatively, we could propagate change at the widget level instead of > the property. So Spec would talk to Adapter? That's exactly what we are trying to avoid.

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Peter UhnÃ¡k

On Sun, May 8, 2016 at 4:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 07-05-16 22:04, Peter UhnÃ¡k wrote: > >> We question whether this belongs to AbstractWidgetModel, as only > three >> (TreeModel, ListModel, and TabModel (iirc)) benefit from it in >> > > any way. > > ContainerModel, DropListModel, ImageModel, LabelModel, MenuModel, > TextModel and WindowModel. > > So no. Can you give me an example of how would you use it with LabelModel? > The same questions also > applies to Styles (color, borderColor, >> borderWidth). Which I would > >> > prefer to remove altogether (it's not really used, and I question > > whether whether it even belongs to Spec side). > > Where would you like to define application style default overrides > then? People ask about this all the time, and the reason it's used so > little is because our implementation in the widgets is so bad: > very inconsistent naming and default styles ignoring overridden values If we separate it, then we can think about how to apply it properly. Right now it's not really possible to unify.

May 8, 2016

Re: [Pharo-dev] Help on using Git with Pharo

by Peter UhnÃ¡k

## 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. ## 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 > > As a user of Git, you need to know the following: > - 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. > - 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 <alexandre.bergel(a)me.com> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

May 8, 2016