- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Iceberg: No Project Founds

by ducasse

> On 2 Jun 2019, at 19:22, Shaping <shaping(a)uurda.org> wrote: > > From a 64-bit Pharo 7.0.3 I cloned UpdatedPharoByExample and immediately saw in red âNo Project Foundâ. Why is this and what must I do to fix it? GitKraken shows that the repo is healthy. But what are you clone a book repo only containing pillar file? Iceberg right now manages code. Try to clone of my Containers-Stack repo to see. > I tried pointing Iceberg in a virgin Pharo to the same folder, got the same result. > > > Shaping

June 2, 2019

Iceberg: No Project Founds

by Shaping

>From a 64-bit Pharo 7.0.3 I cloned UpdatedPharoByExample and immediately saw in red âNo Project Foundâ. Why is this and what must I do to fix it? GitKraken shows that the repo is healthy. I tried pointing Iceberg in a virgin Pharo to the same folder, got the same result. Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by ducasse

> On 2 Jun 2019, at 18:14, Shaping <shaping(a)uurda.org> wrote: > > pay attention Spec2 is in pharo-spec/ > and it is regularly updated in P8 alpha. > > I have P8 dev and donât see a ref to Spec in the package pane filter. check composablePresenter (it is Spec20 > > P8 alpha is not P8 dev? No it is. > > Is the sequence: dev, alpha, beta, release? no alpha=dev > > > We will start to work on the book > We should push Commander2 and start to use it systematically. > https://github.com/SquareBracketAssociates/BuildingApplicationWithSpec2 <https://github.com/SquareBracketAssociates/BuildingApplicationWithSpec2> > > Okay. > > Pavel is moving back to Prague but he can tell you what is doing to port code from VW. > I think that the namespace are not the main problem. > > I need class-naming freedom, mostly, for now. > > We are working on Modules for Pharo now this is tricky and it can impact the complete system. > > Yes, it is very tricky and can cause chaos and destroy much utility if not managed correctly. Since Squeak3.9 Iâm working on removing hardocded usage of Smalltalk instead of an environment or se;lf class environment. So that one day we can try module/namespace for real. Now when porting code from VW to Pharo 1.0 :) I just did a mapping namespace to prefix and change the class name in VW to have prefixName. This is basically what the exporters are doing from VW. > > Adding environment is only a tiny part of the problem. > > I donât have a formal definition for Environment. I tend to think in terms of a VW namespace. Same and I do not like VW namespace with public and private imports I may have pretty printed the code to have ref to class getting the same treatment. > > Shaping > > > >> No, I missed it. Thanks for that. >> >> I have a lot of algorithmic meat in domain classes. Those are easy to port, even if I must manually trip over the minor VW/Pharo differences, and fix them as I come to them, or just run my own VW script to do mass edits on file-outs. I donât mind this part of the conversion much, and it would cover most of what I have port. >> >> I have some special GUIs (2D and 3D) that I need to recode anyway, probably in Spec and Woden. The 3D stuff is now done in Jun OpenGL, which has seen its day, and I suppose wonât be updated to use the OGL shader model. The last update for VW, I think, is from 2015. Iâve had enough of Jun anyway, and would prefer to use Woden in Pharo, or port it to VW, and work on in there. But the GUIs in recent years are not the big issue. The domain objects are. >> >> Mostly, I value reading efficiency. We spend most of our time reading programs so that we can determine how to write some change or new feature without breakage or incongruity. I value reading at high rates and with high comprehension, small methods, and rigidly controlled naming conventions. The ultimate aim is to have the machine reason about my code, with the same or greater grammatical and semantic awareness. This happens now only at a superficial level with classes, methods, and referential, slot-based integrity checks. Iâm happy they are there, but they are not nearly enough to make humans extremely productive and powerful at shaping machine behaviors. I think we are overworked and that our machines are hardly being used. There is a science to increasing reading speed and comprehension in a programming context (and getting the machine to help you in the domain layer), and you canât use that science very well with speed bumps at the beginnings of all the class names. Therefore, I very much value naming classes exactly as I need. Even this is an interim approach. If things go well, classes and methods will go away in the future, but I digress from the near-term task. >> >> I saw the bit near the end of the slides about Spec2. Does this really use GTK to make native GUIs, and does this mean we can have real OS windows on Windows? I miss Alt-Tab-ing for navigating through windows, and would like to see it in the Pharo, but that canât happen without OS windows. Any Windows Pharo users miss Alt-tab-ing? >> >> Can Spec2 be tested in Pharo8 now? >> >> Please point me to the best resources on Spec2. It looks very interesting. I found these: >> >> https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ <https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/> >> >> â >> And thatâs it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately <image001.png> >> Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the people that need it. We will also release Spec20 soon so that people can try Spec 20 â independently of Gtk3 >> â >> >> https://github.com/dionisiydk/Spec2 <https://github.com/dionisiydk/Spec2> >> >> I donât see Spec2 in Pharo 8. I suppose I need to load it. > > No it is directly in. > > >> Is the Spec book still relevant? > > Not fully we will start to port the book. > > >> Is Spec2 mostly about the back-end changes for use of GTK? > > No it is a massive change. > - Introducing new layouts (deprecated the interpreter design) > - soon using Commander2 for menus and the rest > - many many cleans > - Introduction of application and more. > >> >> Shaping >> >> > On 2 Jun 2019, at 12:12, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org>> wrote: >> > >> > >> > >> > I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. >> > The little I know about the topic is that its complicated since it can introduce as many problems as it solves. >> > its something that is wanted, but priorities have taken precedence. >> > A bit work being done in the background should support namespaces when there are resources to "get it right" ... >> > http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t…> >> > >> > For the moment, best best is a few tips on converting from namespaces. >> > http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 <http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334> >> > >> > Thanks for the links. >> > >> > Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. >> > >> > I can learn to deal with Iceberg. >> > >> > >> > Shaping

June 2, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Shaping

Okay. Is one preferred? Tonel Filetree is not nice for Windows users. And Tonel has been designed to solve all the issues of filetree Ok. > For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3? > > Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. Iceberg works very well in 7.x and 8, it is the default after all. You are on Windows, other Windows users should answer. Yes, Windows 10 Pro and running 64-bit Pharo. So tonel is a must for you else you will die. Agreed. I see the bad effects of the Windows 260-character limit with FileTree. Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Shaping

pay attention Spec2 is in pharo-spec/ and it is regularly updated in P8 alpha. I have P8 dev and donât see a ref to Spec in the package pane filter. P8 alpha is not P8 dev? Is the sequence: dev, alpha, beta, release? We will start to work on the book We should push Commander2 and start to use it systematically. https://github.com/SquareBracketAssociates/BuildingApplicationWithSpec2 Okay. Pavel is moving back to Prague but he can tell you what is doing to port code from VW. I think that the namespace are not the main problem. I need class-naming freedom, mostly, for now. We are working on Modules for Pharo now this is tricky and it can impact the complete system. Yes, it is very tricky and can cause chaos and destroy much utility if not managed correctly. Adding environment is only a tiny part of the problem. I donât have a formal definition for Environment. I tend to think in terms of a VW namespace. Shaping No, I missed it. Thanks for that. I have a lot of algorithmic meat in domain classes. Those are easy to port, even if I must manually trip over the minor VW/Pharo differences, and fix them as I come to them, or just run my own VW script to do mass edits on file-outs. I donât mind this part of the conversion much, and it would cover most of what I have port. I have some special GUIs (2D and 3D) that I need to recode anyway, probably in Spec and Woden. The 3D stuff is now done in Jun OpenGL, which has seen its day, and I suppose wonât be updated to use the OGL shader model. The last update for VW, I think, is from 2015. Iâve had enough of Jun anyway, and would prefer to use Woden in Pharo, or port it to VW, and work on in there. But the GUIs in recent years are not the big issue. The domain objects are. Mostly, I value reading efficiency. We spend most of our time reading programs so that we can determine how to write some change or new feature without breakage or incongruity. I value reading at high rates and with high comprehension, small methods, and rigidly controlled naming conventions. The ultimate aim is to have the machine reason about my code, with the same or greater grammatical and semantic awareness. This happens now only at a superficial level with classes, methods, and referential, slot-based integrity checks. Iâm happy they are there, but they are not nearly enough to make humans extremely productive and powerful at shaping machine behaviors. I think we are overworked and that our machines are hardly being used. There is a science to increasing reading speed and comprehension in a programming context (and getting the machine to help you in the domain layer), and you canât use that science very well with speed bumps at the beginnings of all the class names. Therefore, I very much value naming classes exactly as I need. Even this is an interim approach. If things go well, classes and methods will go away in the future, but I digress from the near-term task. I saw the bit near the end of the slides about Spec2. Does this really use GTK to make native GUIs, and does this mean we can have real OS windows on Windows? I miss Alt-Tab-ing for navigating through windows, and would like to see it in the Pharo, but that canât happen without OS windows. Any Windows Pharo users miss Alt-tab-ing? Can Spec2 be tested in Pharo8 now? Please point me to the best resources on Spec2. It looks very interesting. I found these: <https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/> https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ â And thatâs it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately <image001.png> Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the people that need it. We will also release Spec20 soon so that people can try Spec 20 â independently of Gtk3 â <https://github.com/dionisiydk/Spec2> https://github.com/dionisiydk/Spec2 I donât see Spec2 in Pharo 8. I suppose I need to load it. No it is directly in. Is the Spec book still relevant? Not fully we will start to port the book. Is Spec2 mostly about the back-end changes for use of GTK? No it is a massive change. - Introducing new layouts (deprecated the interpreter design) - soon using Commander2 for menus and the rest - many many cleans - Introduction of application and more. Shaping > On 2 Jun 2019, at 12:12, Shaping < <mailto:shaping@uurda.org> shaping(a)uurda.org> wrote: > > > > I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. > The little I know about the topic is that its complicated since it can introduce as many problems as it solves. > its something that is wanted, but priorities have taken precedence. > A bit work being done in the background should support namespaces when there are resources to "get it right" ... > <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t…> http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… > > For the moment, best best is a few tips on converting from namespaces. > <http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334> http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 > > Thanks for the links. > > Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. > > I can learn to deal with Iceberg. > > > Shaping

June 2, 2019

Re: [Pharo-dev] Versioning with Iceberg

by ducasse

> On 2 Jun 2019, at 00:19, Shaping <shaping(a)uurda.org> wrote: > > Is your application making a lot of changes to existing Pharo code? > > Not yet, I just want to explore for a bit, and see what Pharo has to offer. But yes, there will be extensive changes to Pharo, eventually, after I get most of my stuff ported. I need to do some speed tests. Speed is one big issue. Others are: which way do I port code in the short-term and long-term, and can I move all to Pharo and stay there? More immediately, in preparation, I'm trying to get all the creature comforts working the way they do in VW. I prefer the more detailed syntax highlighting in VW. Check the styler look for <style> in Pharo because you can create your own. We need to do one for the dark theme. There are a lot of variations. > I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VWâs. I need to do the same for formatting, which I've not checked out very thoroughly yet. For formatting check the BIformatter. We are working on - adding tests (we have about 150 tests ready to get integrated - working on a new tool to see and understand the settings - we want to make sure that we can pretty print the complete system so we will come probably with an extended pretty printer. > The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paroâand I didnât know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem. Yes this is super annoying. Can you check with Spec 20 and this should be fixed. Now the font logic is one of the few parts that we did not revisit yet but it is not way it should. Also may users hardcode standardFontsâ¦.( the ugly singleton strike back). > > Are you aware of "extension methods" ? Where a method you add to a built-in Pharo class (Collection for example) is saved/loaded with your package. > Then you only need to manage your package not Pharo built-in packages as well. > > Yes, I'm trying to get an Iceberg-on-Git groove going so that I can make my own packages for extensions/overrides. yes us know we can also do some screen sharing with you to get you up to speed. > Thatâs currently where Iâm stuck, and I need to do some VW work this weekend, but I try to work with Pharo as often as I can. > > > > > - if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but wonât load any packages). > > > > After I do the above, Iceberg lists a repo called pharo-smalltalk. Was this intentional? > > Yes, this the the repo name assigned by the Exercism administrators. > The Exercism project has 50 language tracks each with their own repo... https://github.com/exercism <https://github.com/exercism> The Pharo Track repo is https://github.com/exercism/pharo-smalltalk <https://github.com/exercism/pharo-smalltalk> > > > > Above is the Exercism GitHub page. The URL and doc mention both Exercism and pharo-smalltalk, but the former is not found in the GUI anywhere to tell the user what he has (without additional digging). > > I just cloned Exercism. I thought it would be identified somewhere besides in the Git commit comments. The Iceberg repo context menu item Repository (strange name given that we are already in an Iceberg repo) lists the repo as âRepository of pharo-smalltalkâ with a master node, origin node and several version tags. > > Cloning the Pharo Track repo from the command line is done like this... > $ git clone git@github.com:exercism/pharo-smalltalk.git <mailto:git@github.com:exercism/pharo-smalltalk.git> > > Sure, but we can do this in Icebergâand it works. So why use the command line? > > which creates a folder with the same name as the repo (i.e. "pharo-smalltalk") As a git GUI, Iceberg does the same. Indeed, Iceberg uses libgit2 to do this, so the behaviour is standard git. > > I was commenting on the ergonomics, and yes this is very much a Git thing. Git is bad :) but this is the way to go. The API sucks. > > These canât be Pharo versions because the numbers are too small. They must be Exercism versions, > > yes. > > > but âexercismâ isnât mentioned anywhere, except in some of the Git commit comments, or I missed it. So there is some immediate disorientation on that account. If I choose Packages on the Iceberg repo context menu, I can see that this repo is all about Exercism. > > Would a hover tool tip showing "owner/repo" clear this up for you? > > You see the train of thought, broken down that way in steps to show the clumsiness. Hover help seems like an afterthought, but a good oneâmuch better than nothing. Presenting a Smalltalk project in Iceberg without a name when the name (and owner) is known is not âleast astonishingâ. Iâm wondering why someone thought this was okay. I guess we are just mirroring Git as a default. > > Iâm wondering why the name just isnât more prominent in the Git scheme of things and if this is > > @Tim, another way to mitigate such user confusion would be to separate the tools out from https://github.com/exercism/pharo-smalltalk <https://github.com/exercism/pharo-smalltalk> > into https://github.com/pharo-exercism/exercism-tools <https://github.com/pharo-exercism/exercism-tools>. > > > > Would the Iceberg GUI make more sense as a split pane arrangement where the stuff listed in the Repository window is shown in the right pain after selecting a well-named Iceberg repo in the left pane? We could have bubble-help on the listed repos and details in the right pane on repo selection. > > I can't parse that description. A graphical mockup would be more useful to discuss. > > Take the GUI you have already in the Repository window (now opened from the Repository context menu item), and instead make that GUI the right pane in a new GUI, with the current Iceberg repo list becoming the left pane of that new GUI. When using the new GUI, select a repo name in the left pane to see its details populate the right pane. Then go into the right pane, and select a version tag, for example, and do other things with the repo. > > > >> Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. âdevâ for exercism). > > > > I loaded the default baseline and see 4 packages up to date and the rest unloaded. > > Thats right, the default-baseline is for students. The other packages are only required by mentors & maintainers. > > > > When I tried âdevâ I got an assertion failure on the SSH creds. Did I miss a step concerning SSH creds on install? But the loading seemed to continue. > > Given that it already loaded the 4 packages, your SSH creds have already been proven working. > Before considering this further, just need to ask how reliable your internet connection is? > > Very good: 60 Mbps at the low end. > > A poor connection might also explain some of your PharoLauncher "identifying VM version" issues. > > > > I also got the error: > > > > LGit_GIT_EEXISTS: Failed to stat file ' > > F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st <http://testfailedvalidationwhenrequiredsenderreturnedanotherobjectandnobody…>' > > Those very long path names come from a repo in FileTree format. > FileTree format was used by some people to fileout code to work with git from the command outside of Pharo. > > Okay. > > These long path names are fine on Linux, but on Windows libgit2 is constrained by 260 character paths. > > Okay. > > FileTree also had a file per method creating a massive number of small files, which was fine on Linux but a big performance problem on Windows. > To address these issues Tonel format was created with a class per file. > > Okay. So this is an old repo that has not been updated to use Tonel, and all Windows machines will have the name-length limit. I suppose the problem is rare because everyone is converting to Tonel. > > I experienced the same error and fixed it by converting Mocketry to Tonel format here... > github://pharo-exercism/Mocketry <github://pharo-exercism/Mocketry> > and updated the baseline here... > https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfE… <https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfE…> > > Try pulling the `pharo-smalltalk` repo to update it and check it has that line updated. > > Will do. Thanks. > > > Shaping

June 2, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by ducasse

> > > Iâm referring only to a non-default directory for the repo files, which you would think would not matter, or perhaps a file-not-found exception would be raised. But I donât see that. On Windows, the default folder is in an \images subfolder. I currently keep all my Git repos on a separate RAID drive. Ah I also save all my code in a special folder I set with my settings config. > Now on windows the state of the libraries to run scripts is making us trouble > > Can you give more details on that? What are the problems? I do not remember the name :( "OS processâ Now it has a chaotic erratic behavior and it makes the life of the launcher a lot more complex. > and we will have to fix it. > > > > Shaping

June 2, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by ducasse

> On 1 Jun 2019, at 22:52, Shaping <shaping(a)uurda.org> wrote: > > [...] > Tonel (and FileTree) are representations and models of code. > > Okay. Is one preferred? Tonel Filetree is not nice for Windows users. And Tonel has been designed to solve all the issues of filetree > > > For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3? > > > > Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. > > Iceberg works very well in 7.x and 8, it is the default after all. > > You are on Windows, other Windows users should answer. > > > Yes, Windows 10 Pro and running 64-bit Pharo. So tonel is a must for you else you will die.

June 2, 2019

Re: [Pharo-dev] Environments

by ducasse

pay attention Spec2 is in pharo-spec/ and it is regularly updated in P8 alpha. We will start to work on the book We should push Commander2 and start to use it systematically. https://github.com/SquareBracketAssociates/BuildingApplicationWithSpec2 Pavel is moving back to Prague but he can tell you what is doing to port code from VW. I think that the namespace are not the main problem. We are working on Modules for Pharo now this is tricky and it can impact the complete system. Adding environment is only a tiny part of the problem. > No, I missed it. Thanks for that. > > I have a lot of algorithmic meat in domain classes. Those are easy to port, even if I must manually trip over the minor VW/Pharo differences, and fix them as I come to them, or just run my own VW script to do mass edits on file-outs. I donât mind this part of the conversion much, and it would cover most of what I have port. > > I have some special GUIs (2D and 3D) that I need to recode anyway, probably in Spec and Woden. The 3D stuff is now done in Jun OpenGL, which has seen its day, and I suppose wonât be updated to use the OGL shader model. The last update for VW, I think, is from 2015. Iâve had enough of Jun anyway, and would prefer to use Woden in Pharo, or port it to VW, and work on in there. But the GUIs in recent years are not the big issue. The domain objects are. > > Mostly, I value reading efficiency. We spend most of our time reading programs so that we can determine how to write some change or new feature without breakage or incongruity. I value reading at high rates and with high comprehension, small methods, and rigidly controlled naming conventions. The ultimate aim is to have the machine reason about my code, with the same or greater grammatical and semantic awareness. This happens now only at a superficial level with classes, methods, and referential, slot-based integrity checks. Iâm happy they are there, but they are not nearly enough to make humans extremely productive and powerful at shaping machine behaviors. I think we are overworked and that our machines are hardly being used. There is a science to increasing reading speed and comprehension in a programming context (and getting the machine to help you in the domain layer), and you canât use that science very well with speed bumps at the beginnings of all the class names. Therefore, I very much value naming classes exactly as I need. Even this is an interim approach. If things go well, classes and methods will go away in the future, but I digress from the near-term task. > > I saw the bit near the end of the slides about Spec2. Does this really use GTK to make native GUIs, and does this mean we can have real OS windows on Windows? I miss Alt-Tab-ing for navigating through windows, and would like to see it in the Pharo, but that canât happen without OS windows. Any Windows Pharo users miss Alt-tab-ing? > > Can Spec2 be tested in Pharo8 now? > > Please point me to the best resources on Spec2. It looks very interesting. I found these: > > https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ <https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/> > > â > And thatâs it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately <image001.png> > Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the people that need it. We will also release Spec20 soon so that people can try Spec 20 â independently of Gtk3 > â > > https://github.com/dionisiydk/Spec2 <https://github.com/dionisiydk/Spec2> > > I donât see Spec2 in Pharo 8. I suppose I need to load it. No it is directly in. > Is the Spec book still relevant? Not fully we will start to port the book. > Is Spec2 mostly about the back-end changes for use of GTK? No it is a massive change. - Introducing new layouts (deprecated the interpreter design) - soon using Commander2 for menus and the rest - many many cleans - Introduction of application and more. > > Shaping > > > On 2 Jun 2019, at 12:12, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org>> wrote: > > > > > > > > I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. > > The little I know about the topic is that its complicated since it can introduce as many problems as it solves. > > its something that is wanted, but priorities have taken precedence. > > A bit work being done in the background should support namespaces when there are resources to "get it right" ... > > http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t…> > > > > For the moment, best best is a few tips on converting from namespaces. > > http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 <http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334> > > > > Thanks for the links. > > > > Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. > > > > I can learn to deal with Iceberg. > > > > > > Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Ben Coman

On Sun, 2 Jun 2019 at 21:24, Shaping <shaping(a)uurda.org> wrote: > > https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ > > And thatâs it. Pharo 8.0 will come with Spec 2.0 and users will be able to > benefit of it immediately [image: ð] > > Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the > people that need it. We will also release Spec20 soon so that people can > try Spec 20 â independently of Gtk3 > > â > > > > https://github.com/dionisiydk/Spec2 > > > > I donât see Spec2 in Pharo 8. I suppose I need to load it. > > > > Is the Spec book still relevant? Is Spec2 mostly about the back-end > changes for use of GTK? > > > This may interest you... https://www.slideshare.net/pharoproject/spec-20-the-next-step-on-desktop-ui cheers -ben

June 2, 2019