May 2016 - Pharo-dev - lists.pharo.org

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

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

by Stephan Eggermont

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. Alternatively, we could propagate change at the widget level instead of the property. Stephan

May 8, 2016

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

by Stephan Eggermont

On 08-05-16 10:01, stepharo wrote: > Should we apply that for all the announcements? > Do you write tests for this? We should be very clear about when we're setting things up, and when we expect announcements to start being sent. The NewValueHolder class method should be safe. Stephan

May 8, 2016

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

by Stephan Eggermont

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. > for example keep the messages, but delegate the behavior. That is what I was thinking about. As soon as you define drag or drop behavior, instantiate a DragDropSpec. > 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 Stephan

May 8, 2016

Re: [Pharo-dev] Mooc bugs

by stepharo

Thanks I did that too :) Le 8/5/16 Ã 12:06, Cyril Ferlicot D. a Ã©crit : > Le 08/05/2016 10:38, stepharo a Ã©crit : >> When I type >> >> foo >> "bar" >> >> in the editing pain of the System Browser, and then delete the second >> '"' I get the same error as the OP. >> >> When I try to exit the System Browser a debugger oppens up with a >> "Subscript out of bounds" and then the system locks up. >> I was on 32 bit Windows 7 when this happened. >> >> >> Stef >> >> > Hi Stef, > > I already opened an issues about this with Pharo 5 milestone: > https://pharo.fogbugz.com/f/cases/18174/Delete-the-second-of-the-template-m… >

May 8, 2016