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-tp...> http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-tp... 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

Did you see the following presentation (about a VW to Pharo port): Apart Framework: Porting from VisualWorks <https://www.slideshare.net/pharoproject/apart-framework-porting-from-visual works> https://www.slideshare.net/pharoproject/apart-framework-porting-from-visualw orks <http://files.pharo.org/conferences/2019PharoDays/07%20aPart.pdf> http://files.pharo.org/conferences/2019PharoDays/07%20aPart.pdf ? 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/ " And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately 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? Shaping

On 2 Jun 2019, at 12:12, Shaping < <mailto:shaping@uurda.org> 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 p4983800p4990734.html> http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-tp 4983800p4990734.html

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

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@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-tp... <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-tp...>

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

On 2 Jun 2019, at 18:14, Shaping <shaping@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@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-tp... <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-tp...>

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