January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ann] gt connector

by Nicolas Cellier

It sounds great! Le 14 janv. 2018 10:55 PM, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > Hi, > > Towards the end of last year we worked on GT Connector, a new kind of > interface that allows us to exercise and test the limits (or the lack > thereof) of Bloc. > > It looks like this: > > > You can see it in action here: > https://twitter.com/feenkcom/status/936109463462965248 > > In the current implementation, the Connector allows us to navigate and > connect example methods. The focus is not on examples, but on the > connections. We used examples because the engine was already around and > offered us a nice use case. We want to extend it in the near future to > other kinds of objects. > > There are a couple of things that are worth noting: > â¢ The editor works live, and the connection points appear and disappear as > you type. > â¢ The layout of the editor elements is based on a tree-based graph layout > that only works with constrains (no actual visible edges between the editor > elements). > â¢ The editor works live, so adding new elements to the scene properly > rearranges the scene. > â¢ But, perhaps, the most exciting part is the fact that the lines connect > an element from inside the text editor element with another that lives > outside of the editor element. > > All these validate the architecture of Bloc of having exactly one > rendering tree. It was not an obvious goal a couple of years ago, but we > are really happy that it works. > > To put it in perspective, let's compare this with the html world. Text is > text is rendered through the DOM tree. If you want graphics you might > use something like SVG which comes with its own tree. However, these are > two distinct worlds, and you cannot go from one to another, or at least > not easily. This is the case in most engines we looked at. > > Why is this important? One thing we learn in the Smalltalk world is that > covering the same space with less concepts opens up a whole dimension > of creativity that is simply not possible outside of it. > > The goal with Bloc is to enable new kinds of user interfaces. As we are > late to the game of modern interfaces, even though the field was invented > in Smalltalk, our only chance to take the lead again is to rethink the > model. > > Let's look at the Connector again. In most user interfaces we have panes > on the outside, and visuals confined within the boundaries of those > panes. Interestingly, we can trace this pattern to the very first Smalltalk > interfaces. In the Connector interface we have no boundaries with text > and visualization being intertwined to form a new kind of workflow. > > Talking about workflows, we now have two distinct and novel ways to > explore examples: one is Connector, and the other one is the expandable > code editor. For example, the scene from above looks like this in the > example expanding editor: > > > > > Both of these interfaces are not found in other infrastructures, and yet > they were both inexpensive to implement in Bloc. > > We believe this will have a deep impact for all sorts of interfaces, and > especially for the IDE. If you are interested in more details related to > the IDE, take a look at the following paper from 2015: > http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualization > s.pdf > > Please let us know what you think. > > Cheers, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > >

Jan. 14, 2018

Re: [Pharo-dev] git and author/timestamps, 10000's of files, etc.

by Nicolas Cellier

Hi Dale, What is the atomic change considered? Method level or line level? In the first case, author and timestamps won't conflict unless the method conflicts. Sure, it is redundant with git data if using git exclusively and if caring to import history like with gitsvn... in a context of exchange with others it's not. Le 14 janv. 2018 7:12 PM, "Dale Henrichs" <dale.henrichs(a)gemtalksystems.com> a Ã©crit : > I've been skimming the ironically named "blame" thread and just want to > clear up some apparent misconceptions. > > git/github is not the reason that the author/timestamps information was > "lost" ... when tonel was introduced the author/timestamp info was not > included in the format as a separately serialized file. filetree's > implementation of author/timestamp support (around for almost 6 years now) > was an annoying source of commit conflicts and often prevented automatic > merges. > > git/github has perfectly functional blame support[1], so the decision to > rely on git for supplying the author/timestamp for tonel was a sound > decision. Thierry Goubier's GitFileTree[2] implementation does a very good > job of converting git author/timestamp information into Monticello meta > data, and is proof that author/timestamp information can be extracted from > a git repository. > > AFAICT, the single issue here is that the code to link between git's > author/timestamp information and the in-image author/timestamp information > has not been written YET ... > > git/github is not the reason that there are "1000's of files on disk". > Tonel uses a file per class format which significanly reduces the file > count for Smalltalk repositories on disk. FileTree format uses a file per > method format and for large projects leads to a large number of files, > which in and of itself is not a problem (at least for git), but does lead > to excessive disk space consumption. > > SmalltalkCI[2], which provides support for Smalltalk on travis-ci[3] and > appveyory[4] was created by Fabio Niephaus an active member of the Squeak > community. Travis-ci makes it possible to run cross-dialect tests to > validate github pull requests and checkins[5] for cross-dialect projects. > > It seems that there are at least some (less vocal) members of the Squeak > community who are interested in using git. > > Dale > > [1] https://www.git-scm.com/docs/git-blame > [2] https://github.com/hpi-swa/smalltalkCI > [3] https://travis-ci.org/ > [4] https://www.appveyor.com/ > [5] https://travis-ci.org/Metacello/metacello > >

Jan. 14, 2018

[ann] gt connector

by Tudor Girba

Hi, Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc. It looks like this: You can see it in action here: https://twitter.com/feenkcom/status/936109463462965248 In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects. There are a couple of things that are worth noting: â¢ The editor works live, and the connection points appear and disappear as you type. â¢ The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements). â¢ The editor works live, so adding new elements to the scene properly rearranges the scene. â¢ But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element. All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works. To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at. Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it. The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model. Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow. Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor: Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc. We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015: http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… Please let us know what you think. Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

Jan. 14, 2018

bloc next experiments

by Tudor Girba

Hi, Happy New Year! We were asked about the roadmap of Bloc several times. It is a perfectly reasonable request given that Bloc is supposed to offer the UI infrastructure for the future of Pharo. However, I was reluctant to provide one because we do not really have a classic roadmap. When we develop Bloc and GT we think in terms of experiments and examples that we want to play with to get us to our goal. Features are a consequence of that. This approach allowed us on multiple occasions to stumble across functional possibilities that we would have not been able to think about before seeing the experiments. It also works the other way around: as we move ahead, we sometime discover modeling problems and we sometimes chase them all the way down. Having said that, we can specify the next examples and experiments that we consider for the next months. Here they are: â¢ Drag and drop that can be customized on an instance basis. In the process, revisit event management and explore making it use Announcements. Use this for the diagramming engine. â¢ Scrollbar for infinite list and the scalable element. â¢ Apply layout once. For example, this would allow us to apply a layout but still be able to drag elements in custom positions without disturbing the others. The first application is in the context of creating diagrams and visualizations. â¢ Apply layout with animation. For example, in Connector, a new example should be spawned and moved to its position through a smooth animation. This will also allow us to play with the concept of animation and MVVM. â¢ Introduce the concept of elevation. This is important for scenes in which we have overlapping elements that are not part of the composition tree. For example, in Connector, the lines connect inner elements inside the text, but they belong to the root. such as a visualization (but not only). For this to work, we need a better element traversing structure. â¢ Experiment with theming. The theming mechanism should be instance specific with per-widget defaults, and the theme values should ideally be injected in the widgets. The CSS implementation from Glenn is one direction. As developing and maintaining themes can be a nightmare in the long run, the theming mechanism to provide debugging tools. â¢ Experiment with delegating animations through the model. Typical MVVM or MVC focus on the behavior of an interaction. We want to get smooth live interfaces and the animation logic should be influence-able by the model. For example, hovering over a button, enlarges the button with extra details about the action. â¢ Basic widgets: list, input box, button, radio button, checkbox, menu, dropdown menu, toggling button, tabs, toolbar. â¢ Table and tree widgets. â¢ Pager interface (similar to the one in the current inspector) with resizable panes. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Jan. 14, 2018

git and author/timestamps, 10000's of files, etc.

by Dale Henrichs

I've been skimming the ironically named "blame" thread and just want to clear up some apparent misconceptions. git/github is not the reason that the author/timestamps information was "lost" ... when tonel was introduced the author/timestamp info was not included in the format as a separately serialized file. filetree's implementation of author/timestamp support (around for almost 6 years now) was an annoying source of commit conflicts and often prevented automatic merges. git/github has perfectly functional blame support[1], so the decision to rely on git for supplying the author/timestamp for tonel was a sound decision. Thierry Goubier's GitFileTree[2] implementation does a very good job of converting git author/timestamp information into Monticello meta data, and is proof that author/timestamp information can be extracted from a git repository. AFAICT, the single issue here is that the code to link between git's author/timestamp information and the in-image author/timestamp information has not been written YET ... git/github is not the reason that there are "1000's of files on disk". Tonel uses a file per class format which significanly reduces the file count for Smalltalk repositories on disk. FileTree format uses a file per method format and for large projects leads to a large number of files, which in and of itself is not a problem (at least for git), but does lead to excessive disk space consumption. SmalltalkCI[2], which provides support for Smalltalk on travis-ci[3] and appveyory[4] was created by Fabio Niephaus an active member of the Squeak community. Travis-ci makes it possible to run cross-dialect tests to validate github pull requests and checkins[5] for cross-dialect projects. It seems that there are at least some (less vocal) members of the Squeak community who are interested in using git. Dale [1] https://www.git-scm.com/docs/git-blame [2] https://github.com/hpi-swa/smalltalkCI [3] https://travis-ci.org/ [4] https://www.appveyor.com/ [5] https://travis-ci.org/Metacello/metacello

Jan. 14, 2018

Re: [Pharo-dev] Tonel code?

by Dale Henrichs

Javier, I have a port of Tonel to GemStone[1] that runs against both Monticello and CypressReferenceImplementation[2]. I have yet to merge my work back into pharo-vcs/tonel, because I'm waiting for Tonel to stabilize and well ... I'm also busy:). It might be useful for you to see how I've spliced in readers and writers for both Monticello and CypressReferenceImplementation. The CypressReferenceImplementation was written by Richard Sargent as a non-Monticello-based package loader and has been ported to VW and GemStone. Richard's work was based on some work that I had done in creating a Cypress format[3] loader for Cuis[4] The CypressReferenceImplementation is definition-based like Monticello, but the definition model has been pared down to bare essentials. It was written to be a reference implementation for other non-Monticello-based Smalltalk platforms. Unless you already have a native definition-based system you should look at the CypressReferenceImplementation for inspiration. Anyway, I'd be willing to answer any questions you have on the work I've done with Tonel and the CypressReferenceImplementation and I'd especially be interested on any improvements you migiht suggest as I'm currently working on a second generation implementation of the CypressReferenceImplementation called Rowan[5] that is targeted for inclusion in the next GemStone release:) Dale [1] https://github.com/GsDevKit/tonel [2] https://github.com/dalehenrich/CypressReferenceImplementation/tree/portabil… [3] https://github.com/CampSmalltalk/Cypress [4] https://github.com/CampSmalltalk/cuis-cypress [5] https://github.com/dalehenrich/CypressReferenceImplementation/tree/rowan/to… On 1/13/18 7:56 AM, Javier PimÃ¡s wrote: > Hi, I wanted to do some dialect porting experiments. I want to export > to pharo using tonel file format and got some questions. > > 1. Is this the main source? https://github.com/pharo-vcs/tonel > <https://github.com/pharo-vcs/tonel> > 2. Is it already loaded in pharo 7? > 3. Seems to have dependencies with monticello, how hard would it be to > have a port without monticello/port the needed monticello dependencies? > 4. Any advice? > > Cheers, > Javier > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires

Jan. 14, 2018

Re: [Pharo-dev] Tonel code?

by Stephane Ducasse

> Hi, I wanted to do some dialect porting experiments. I want to export to > pharo using tonel file format and got some questions. > > 1. Is this the main source? https://github.com/pharo-vcs/tonel yes > 2. Is it already loaded in pharo 7? did you open Pharo 70? because this is what I should do to answer your question. > 3. Seems to have dependencies with monticello, how hard would it be to have > a port without monticello/port the needed monticello dependencies? No idea. > 4. Any advice? > > Cheers, > Javier > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires

Jan. 14, 2018

Re: [Pharo-dev] Spec dynamic layout without dynamic widgets

by Stephane Ducasse

Hi hernan On Sat, Jan 13, 2018 at 10:31 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi guys, > > A comment from building Spec layouts for widgets (Pharo 6 but maybe > applicable to Pharo >= 7): I have built a Spec widget which could have > two layouts: #buttonsOnTopSpec and #buttonsOnBottomSpec : > > SpcLabeledActionsList new > openWithSpec: #buttonsOnTopSpec; > yourself. > > SpcLabeledActionsList new > openWithSpec: #buttonsOnBottomSpec; > yourself. We started to revisit Spec with Pavel and we got distracted. I really think that Spec needs a good pass to redesign some parts. You may encounter one missing hooks. I should add the new hook that we introduce before forgetting. And I should have a look at Peter attemps to rewritte the interpreter. > Now if you would have to set such list as a widget in > #initializeWidgets, the building process follows its path to > #private_buildWithSpec which hardcodes the spec layout to the > #defaultSpecSelector (the one containing <spec: #default> pragma). > > The problem subclassing from DynamicComposableModel / Presenter is > that is trying to solve two problems at once: > > 1) Dynamic adding/removing widgets > 2) Dynamic configuration of layout > > In this case I just need the 2), and I would have to remove inst. vars > and accessors in ~20 classes because the dynamic widgets dictionary > now stores all widgets, or interject a weirdo between > ComposableModel/Presenter and DynamicComposableModel/Presenter. Do you have the code somewhere because this is really a scenario that dynamicModel should support. I'm thinking aloud... may be we should add a variable holding the spec to be used and the initializeWidgets should use it when set. Does it make sense? > > What would you do? > > Cheers, > > HernÃ¡n >

Jan. 14, 2018

Re: [Pharo-dev] Blame support P7

by Stephan Eggermont

Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > (1) what non-trivial code is actively maintained from a single code base > between Pharo, Squeak and Cuis ? That is nice, but too limited a question What about the need to maintain non-trivial large code bases between multiple smalltalks? If we only limit ourselves to open source, just look at Glorp and PDFTalk. Stephan

Jan. 14, 2018

pharo 6.1 iceberg problem with latest windows (32bit) VM

by Sanjay Minni

Using Pharo 6.1 with the latest windows 32 bit VM, i get the following message when trying to use world->tools->iceberg "This version of iceberg required libgit2 0.25.1, you have 0.23.0, pls update your PharoVM" regards Sanjay ----- --- Regards, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 14, 2018