- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

> On 14 Jan 2018, at 22:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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: > <connector2.jpeg> > > You can see it in action here: > https://twitter.com/feenkcom/status/936109463462965248 Incredible stuff ! Keep on pushing the boundaries. > 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: > > <editor.jpg> > > > 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?" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 15, 2018

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

by Sven Van Caekenberghe

> On 15 Jan 2018, at 11:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > >> On 15 Jan 2018, at 10:44, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> >> >> On Sun, Jan 14, 2018 at 7:11 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> 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 ... >> >> Actually, I remember Esteban doing a prototype some months ago. The idea was to query author/timestamp information from git just after bootstrapping, and to embed this information in the resulting image. >> The problem is that this approach was SUPER slow, because it had to blame on each method. And increasing the build times is not very nice because it kind of slows down the frequency of integrations, specially during sprints. >> >> Now, each commit usually changes only a couple of methods, so author/timestamp of methods will remain the same for 99.9% of the methods most of the time. It would be possible to cache it and re-calculate the new ones following the commit diff. At least this would restore the timestamp of the methods found in the image. >> >> A second point, and orthogonal to the previous one, would be to also manage the "browse versions". Today the version browser queryies only the changes file. I think it would make sense to do it by epicea files (for local modifications) and then fallback to a git repository (if any) to give a full history. Technically, it should not be difficult to do, except for the detail that the repository was transformed at some point from filetree to tonel, so blame will not quite work out of the box :). > > yes. We explored this and there is a âlogâ functionality already in iceberg, that works for filetree. > Iâm working on make it work for tonel. > > As I said we made the experiment, but then after analysis we realise that is very slow and even if we could cache. etc. , we also realised that we do not need to reproduce the same behaviour to have the desired result. > > So, we are going to change the way author/timestamp work: > > you will see you in-image versions as now, but then if you want to see everything of a method you will have a button in versions browser that will fill ALL method history, taken from the git repository. This full history will provide correct authorship and an extra, very valuable bonus: you will see the method history from the moment he is born (you canât have this with plain monticello today) That is what we want/need. Esteban, our hero ! > cheers, > Esteban > > >> >> >> 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 >> >> >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13

Jan. 15, 2018

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

by Esteban Lorenzano

Hi, > On 15 Jan 2018, at 10:44, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Sun, Jan 14, 2018 at 7:11 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: > 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 ... > > Actually, I remember Esteban doing a prototype some months ago. The idea was to query author/timestamp information from git just after bootstrapping, and to embed this information in the resulting image. > The problem is that this approach was SUPER slow, because it had to blame on each method. And increasing the build times is not very nice because it kind of slows down the frequency of integrations, specially during sprints. > > Now, each commit usually changes only a couple of methods, so author/timestamp of methods will remain the same for 99.9% of the methods most of the time. It would be possible to cache it and re-calculate the new ones following the commit diff. At least this would restore the timestamp of the methods found in the image. > > A second point, and orthogonal to the previous one, would be to also manage the "browse versions". Today the version browser queryies only the changes file. I think it would make sense to do it by epicea files (for local modifications) and then fallback to a git repository (if any) to give a full history. Technically, it should not be difficult to do, except for the detail that the repository was transformed at some point from filetree to tonel, so blame will not quite work out of the box :). yes. We explored this and there is a âlogâ functionality already in iceberg, that works for filetree. Iâm working on make it work for tonel. As I said we made the experiment, but then after analysis we realise that is very slow and even if we could cache. etc. , we also realised that we do not need to reproduce the same behaviour to have the desired result. So, we are going to change the way author/timestamp work: you will see you in-image versions as now, but then if you want to see everything of a method you will have a button in versions browser that will fill ALL method history, taken from the git repository. This full history will provide correct authorship and an extra, very valuable bonus: you will see the method history from the moment he is born (you canât have this with plain monticello today) cheers, Esteban > > > 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 <https://www.git-scm.com/docs/git-blame> > [2] https://github.com/hpi-swa/smalltalkCI <https://github.com/hpi-swa/smalltalkCI> > [3] https://travis-ci.org/ <https://travis-ci.org/> > [4] https://www.appveyor.com/ <https://www.appveyor.com/> > [5] https://travis-ci.org/Metacello/metacello <https://travis-ci.org/Metacello/metacello> > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Jan. 15, 2018

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

by Guillermo Polito

On Sun, Jan 14, 2018 at 7:11 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > 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 ... > Actually, I remember Esteban doing a prototype some months ago. The idea was to query author/timestamp information from git just after bootstrapping, and to embed this information in the resulting image. The problem is that this approach was SUPER slow, because it had to blame on each method. And increasing the build times is not very nice because it kind of slows down the frequency of integrations, specially during sprints. Now, each commit usually changes only a couple of methods, so author/timestamp of methods will remain the same for 99.9% of the methods most of the time. It would be possible to cache it and re-calculate the new ones following the commit diff. At least this would restore the timestamp of the methods found in the image. A second point, and orthogonal to the previous one, would be to also manage the "browse versions". Today the version browser queryies only the changes file. I think it would make sense to do it by epicea files (for local modifications) and then fallback to a git repository (if any) to give a full history. Technically, it should not be difficult to do, except for the detail that the repository was transformed at some point from filetree to tonel, so blame will not quite work out of the box :). > 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 > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 15, 2018

Pavel's ChangeLog week of 2018-01-08

by Pavel Krivanek

I was continuing on work on Ring 2 integration. The image with replaced Ring versions can be bootstrapped and most of the failing tests are fixed. The most problematic part is Epicea adoption. I improved the optional resolving granularity in Ring 2 and added new cleaning mechanisms of the environments but some work still left. In past we had a MethodReference class that was then replaced with Ring models. With the Ring 2 integration a similar class will be re-introduced because the models in Ring 2 are more complex and they are not the best option for cases where only a simple model with a method class name and selector is needed - e.g. for code coverage etc. It is important that such reference class will NOT be polymorphic with real methods because people then tend to mix usage of models and real system. Small tip. When you want to work on an image that was created by the CI from a pull request and you want to make next commits based on it (it can be a PR done by someone else), you will probably see this error when you will try to reload packages: IceError: Your repository seems to be out of sync.! Please fetch from "noname (git@github.com:pharo-project/pharo.git)" and try again. It is caused by the fact that the versions that are loaded in the image are based on merging commits done by the CI that are not present in any repository. Iceberg then cannot find them and so no fetch will help. It can be solved by reloading of the packages from the Tonel working copy on disk. Then you can finally reload the packages from the Git repository. It should not be done in a single pass so that's why the code looks so strange: pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo' ]. repository := TonelRepository new directory: (pharoRepository location / pharoRepository subdirectory); yourself. (pharoRepository savedPackages select: [:aPackage | aPackage isLoaded ]) do: [ :package | [ (repository loadVersionFromFileNamed: package name) load. ] on: MCMergeOrLoadWarning do: [:warning | warning resume: true ]]. (pharoRepository savedPackages select: [:aPackage | aPackage isLoaded ]) do: [ :package | [ package reload ] on: MCMergeOrLoadWarning do: [:warning | warning resume: true ]]. Cheers, -- Pavel

Jan. 15, 2018

Re: [Pharo-dev] pharo 6.1 iceberg problem with latest windows (32bit) VM

by Esteban Lorenzano

you are using an older VM, you need to update it. wget -O- get.pharo.org/vm61 <http://get.pharo.org/vm61> | bash Esteban > On 14 Jan 2018, at 05:21, Sanjay Minni <sm(a)planage.com> wrote: > > 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. 15, 2018

Re: [Pharo-dev] [Pharo-users] Pharo Lecture at Tunis next week

by Serge Stinckwich

Thank you StÃ©phane for your continued effort to do Pharo lectures all around the world. I try do to the same in Cameroon. On Sat, Jan 13, 2018 at 1:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys > > just to tell you that next week I will give a lecture at ENIS at tunis. > 3 full days of Pharo and advanced design. > > Stef > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

Jan. 15, 2018

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

by HernÃ¡n Morales Durand

Hi Stef, 2018-01-14 8:53 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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. > I think one of the challenges is to add support for a good layout model (there was a thread about layout recently). Or do you mean rewrite the interpreter for efficency issues? > >> 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. Yep, you can install it in Pharo 6 with: Metacello new smalltalkhubUser: 'hernan' project: 'SpecUIAddOns'; configuration: 'SpecUIAddOns'; version: #bleedingEdge; load: 'Core' SpcEditableActionList example2. SpcEditableActionList example3. > 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? > Yes, it does. I did something similar, but I don't want to touch ComposableModel. So in the SpecUIAddOns I added a class SpcDynamicLayoutPresenter holding a layoutSpecSelector which is used in #private_buildWithSpec. Cheers, HernÃ¡n

Jan. 15, 2018

a summary of the "blame" thread

by Dale Henrichs

The recent "blame" thread seems to have touched on a sore point for some folks and the discussion has devolved into a melee of clashingÂ (s)words -- which in general is pretty counter-productive. I read through each of the messages in the thread and tried to pick out the concrete questions/issues that were brought up. I ignored the many meta arguments that went on and I may have missed some subthreads of importance, but I was surprised at the number of issues that were raised in the course of two days:): the lost author/timestampsÂ subthread the exchange code between dialects subthread the what is collaboration subthread the git is not smalltalk subthread the central server vs distributed server subthread the git support is important to new business subthread the iceberg has bugs, therefore it is wrong to use git subthread the Monticello is perfect so it isn't necessary to use git subthread the it works for me there it will work for everyone subthread the multi-platform support subthread the we at y think git is cool, but disagree with the approach taken by z subthread Each of these points/issues/arguments for the most part is important, some not so important and some already addressed, but amazingly the vast majority of the topic never got a reply as some of these threads were buried in a message that also contained meta arguments. In re-reading the list it is clear to me that my personal bias crept into the short summary, but frankly when I reread those messages I wasn't able to summarize the actual point, because it was not necessarily clear what the real point was --- not enough detail --- I included it with my funky interpretation because it is probably worth discussing at some level, but the discussion deserves more substance. I seems to me that each of the dialects in play: Cuis, Pharo, Squeak, and GemStone has consistent answers to each of the subthreads, but perhaps it is the cross-platform nature of of the issues that is at the core of the arguments ... Pharo has taken the bull by the horns and committed to using git/github for the Pharo kernel source code and thereby committed to making it easy to use git (and presumably other disk-based SCMs ... eventually) from within the Pharo7.0 image ... the decision has been made and the conversion pains are being felt (which is not unexpected). Clearly this move by Pharo does have an (eventual?/varying) impact on the other Smalltalk dialects. For GemStone we are moving pretty much in the same direction as Pharo is moving and for many of the same reasons ... I have been grumpy about the unilateral move to Tonel, but We are expecting to introduce git/package/Metacello support in the base in the next release of GemStone (just a simple matter or resources:). We are using Tonel and git in our internal product development process in a limited way. Besides the obvious reasons, Metacello support is there so that our customers who are not using GsDevKit can have the option of loading/contributing to open source Smalltalk projects hosted on github. We do not plan to support .mcz files in the kernel. We will most likely base our kernelÂ git tools support on bash command line git (a feature that has been in tODE for about 5 years). Our server product is not supported on Windows, so we can get away with that.. Windows clients are supported, but not Windows servers. With regards to central vs. distributed server, we lean towards distributed servers. We have a number of customers whose production systems are behind firewalls that make it very difficult if not impossible for the Smalltalk developers to access network-based Monticello web-sites let alone CVS-style centralized servers. So making it possible for those developers to use local git clones "transparently" is a seen as a real advantage ... Finally our open source GsDevKit project has a Pharo compatibility layer, so being able to share source code with Pharo is a priority and Metacello is a key component in that support. Monticello .mcz files will continue supported in GsDevKit as long as the critical projects for customers continue to be hosted inÂ Monticello .mcz repositories ... eventually I expect .mcz support to become an optional component in GsDevKit, but I won't put a date on it since I do expect to support Monticello for some definition of forever:) Dale

Jan. 14, 2018

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