November 2016 - Pharo-users

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

by Nicolai Hess

2016-11-03 15:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-11-03 15:02 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi nicolai >> >> I started to work on the reflection chapter. >> > > > The reflection chapter (and maybe some other too) could new some new > screenshots. > Actually, the reflection chapter needs some more rewrites (not only updated screenshots). Some examples just aren't applicable anymore because we don't have refactoring browser preinstalled and although Nautilus can do alot, its missing the full set of menus for creating scoped environments. I'll try to rewrite those parts. > Now hacking PharoDoc :) >> >> Stef >> >> Le 3/11/16 Ã 14:29, Nicolai Hess a Ã©crit : >> >> >> >> 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> In case someone missed it I will be doing a release for version 5 (pharo >>> version = pbe version) this weekend , since we had Pharo 7 initiated few >>> days ago. >>> >>> Essentially that means that the repo will be tagged for version 5, which >>> means a git commit is associated as a last commit for that version and >>> there will be a frozen release - download for Pharo by Example version 5. >>> After that we move to Pharo By Example version 6 or PBE6 for short >>> >>> The repo wont change otherwise and the process of submitting commits, >>> pull requests and issues remains the same. >>> >>> If you have found a flaw of any sort in the documentation , please open >>> an issue in the github issue tracker that can be found here >>> >>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues >>> >>> I will try to fix any problem reported but if I cannot , the fix will >>> have to move to version 6 >>> >>> As always thanks to all people contributing into the impossible .... >>> making Pharo more amazing >>> >>> If you want to contribute feel free to do so with a pull request. >>> >>> Does not matter if you are beginner because even minor corrections like >>> correcting mistakes in the grammar or content of the text, updated >>> pictures, or just a few lines of extra info are more than enough and more >>> than welcomed. Many Pharo beginners have already done so . >>> >>> -Salute to fellow Guardians of The Light >>> >> >> I found some problems, but I don't have time to report/fix them now, I >> 'll try to report them >> later (today or tomorrow). >> >> >> >> >

Nov. 6, 2016

Re: [Pharo-users] About balkanisation

by Offray Vladimir Luna CÃ¡rdenas

And for us, without Git :-). Offray On 06/11/16 13:27, Dimitris Chloupis wrote: > I agree Pharo works great for me with Git apart from the file tree issue. > On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi, > > This thread derived on using GitHub, the transitions to it, the > mismatch > between the Smalltalk code model and the files code model. I would > like > to offer another view. > > Pharo is working pretty well here. We have just finished our seventh > edition of the Data Week workshop+hackathon. This time we explored the > fossil DCVS and make some templates with mustache to > export/publish some > data visualizations. The infrastructure we have now doesn't get in our > way, installing the software with Catalog, updating with Monticello, > syncing changes while the workshop is happening, working with teapot, > tealight and the mustache binding all that went pretty smooth. The > supporting documentation for these tools was of great help. > > Nicolas is making a good job in making the transition to Git/GitHub > smooth, but at the same time he is having a critical perspective > on git > and its workflow (which is not the best for every community, case or > project) and I think that's healthy, so we don't need to make Pharo > conform to git. > > So I just want to add that there are other places and people > (mostly not > developers), here in Colombia, South America, that really appreciate > what the Pharo ecosystem, in its current form, is offering: its fluid, > uniform, connected, self contained, and powerful. It is a breath of > fresh air in the current overcomplicated technology. I just hope that > the migration and evolution preserve and maximize that. Keeping the > equilibrium between fast feedback, change, diversity, balkanisation, > visibility and hyper trendy is difficult, but hopefully the core > experience that Pharo is providing, will guide such equilibrium, and > continue to serve its several communities around the world. > > Cheers, > > Offray > > > On 06/11/16 07:05, stepharo wrote: > > Hi > > > > I would like that you think a bit about our community and that there > > is a value in using common tools > > > > to share and develop common libraries. Because to me it feels > like we > > are getting balkanize. > > > > > > It may look super cool and be hyper trendy to use github > (because like > > that you can say that you use latest hyper cool > > > > features), but I would like to ask especially people building > > libraries to pay attention that it is important > > > > that other people can contribute back easily and that there is > an easy > > way to load/contribute. > > > > Today I experienced Bloc > > > > - I cannot load code and I cannot contribute. > > > > - I saw mdl with a mixture between smalltalkhub and github > (sounds > > super hyper cool) and I saw paul not being able to contribute :( > > > > > > Yes you can say that monticello sucks yes it is terrible yes we all > > fell like Cobol programmers but at the end of the day. > > > > Yes the herb is always greener elsewhere. Yes yes yes. Let us take > > some facts. > > > > We managed pharo and moose with it over the last 8 years > successfully > > and Pharo and moose are not 5 packages together from > > > > what I can see. So pay attention about the decision you take. > > > > Now we will provide git support (this is 8 months that nicolas is > > exclusively working/thinking/dreaming > > > > about that) and that we are doing experiments (Guille is > managing the > > bootstrap in github). > > > > Now when everybody will have its own little project lost on > github (I > > do not count the amount of time I do not find pillar on github > because > > I forget > > > > that it is called pillar-markup), what will we do. > > > > So we need an infrastructure to handle this and christophe is > working > > on this. > > > > I think that you should consider the accidental complexity as > > something that we can minimise by using patterns and common > practices. > > > > Now you can think that I'm an idiot and that I have no vision (be my > > guest) but we should pay attention because we are a small community. > > > > Stef > > > > > > > > > > > >

Nov. 6, 2016

Re: [Pharo-users] About balkanisation

by Dimitris Chloupis

The commit messages, say nothing about the commits On Sun, 6 Nov 2016 at 17:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 6 Nov 2016, at 16:27, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > A biggy one is the pharo repo of the pharo image on github. Its a mess. > > > > https://github.com/pharo-project/pharo-core/commits/6.0 > > > > seriously, Github makes us visible , this does not look good at all. > > why not ? how is this different from a multi file commit in any other > language ? > > >

Nov. 6, 2016

Re: [Pharo-users] About balkanisation

by Dimitris Chloupis

I agree Pharo works great for me with Git apart from the file tree issue. On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi, > > This thread derived on using GitHub, the transitions to it, the mismatch > between the Smalltalk code model and the files code model. I would like > to offer another view. > > Pharo is working pretty well here. We have just finished our seventh > edition of the Data Week workshop+hackathon. This time we explored the > fossil DCVS and make some templates with mustache to export/publish some > data visualizations. The infrastructure we have now doesn't get in our > way, installing the software with Catalog, updating with Monticello, > syncing changes while the workshop is happening, working with teapot, > tealight and the mustache binding all that went pretty smooth. The > supporting documentation for these tools was of great help. > > Nicolas is making a good job in making the transition to Git/GitHub > smooth, but at the same time he is having a critical perspective on git > and its workflow (which is not the best for every community, case or > project) and I think that's healthy, so we don't need to make Pharo > conform to git. > > So I just want to add that there are other places and people (mostly not > developers), here in Colombia, South America, that really appreciate > what the Pharo ecosystem, in its current form, is offering: its fluid, > uniform, connected, self contained, and powerful. It is a breath of > fresh air in the current overcomplicated technology. I just hope that > the migration and evolution preserve and maximize that. Keeping the > equilibrium between fast feedback, change, diversity, balkanisation, > visibility and hyper trendy is difficult, but hopefully the core > experience that Pharo is providing, will guide such equilibrium, and > continue to serve its several communities around the world. > > Cheers, > > Offray > > > On 06/11/16 07:05, stepharo wrote: > > Hi > > > > I would like that you think a bit about our community and that there > > is a value in using common tools > > > > to share and develop common libraries. Because to me it feels like we > > are getting balkanize. > > > > > > It may look super cool and be hyper trendy to use github (because like > > that you can say that you use latest hyper cool > > > > features), but I would like to ask especially people building > > libraries to pay attention that it is important > > > > that other people can contribute back easily and that there is an easy > > way to load/contribute. > > > > Today I experienced Bloc > > > > - I cannot load code and I cannot contribute. > > > > - I saw mdl with a mixture between smalltalkhub and github (sounds > > super hyper cool) and I saw paul not being able to contribute :( > > > > > > Yes you can say that monticello sucks yes it is terrible yes we all > > fell like Cobol programmers but at the end of the day. > > > > Yes the herb is always greener elsewhere. Yes yes yes. Let us take > > some facts. > > > > We managed pharo and moose with it over the last 8 years successfully > > and Pharo and moose are not 5 packages together from > > > > what I can see. So pay attention about the decision you take. > > > > Now we will provide git support (this is 8 months that nicolas is > > exclusively working/thinking/dreaming > > > > about that) and that we are doing experiments (Guille is managing the > > bootstrap in github). > > > > Now when everybody will have its own little project lost on github (I > > do not count the amount of time I do not find pillar on github because > > I forget > > > > that it is called pillar-markup), what will we do. > > > > So we need an infrastructure to handle this and christophe is working > > on this. > > > > I think that you should consider the accidental complexity as > > something that we can minimise by using patterns and common practices. > > > > Now you can think that I'm an idiot and that I have no vision (be my > > guest) but we should pay attention because we are a small community. > > > > Stef > > > > > > > > > > > > >

Nov. 6, 2016

Re: [Pharo-users] About balkanisation

by Offray Vladimir Luna CÃ¡rdenas

Hi, This thread derived on using GitHub, the transitions to it, the mismatch between the Smalltalk code model and the files code model. I would like to offer another view. Pharo is working pretty well here. We have just finished our seventh edition of the Data Week workshop+hackathon. This time we explored the fossil DCVS and make some templates with mustache to export/publish some data visualizations. The infrastructure we have now doesn't get in our way, installing the software with Catalog, updating with Monticello, syncing changes while the workshop is happening, working with teapot, tealight and the mustache binding all that went pretty smooth. The supporting documentation for these tools was of great help. Nicolas is making a good job in making the transition to Git/GitHub smooth, but at the same time he is having a critical perspective on git and its workflow (which is not the best for every community, case or project) and I think that's healthy, so we don't need to make Pharo conform to git. So I just want to add that there are other places and people (mostly not developers), here in Colombia, South America, that really appreciate what the Pharo ecosystem, in its current form, is offering: its fluid, uniform, connected, self contained, and powerful. It is a breath of fresh air in the current overcomplicated technology. I just hope that the migration and evolution preserve and maximize that. Keeping the equilibrium between fast feedback, change, diversity, balkanisation, visibility and hyper trendy is difficult, but hopefully the core experience that Pharo is providing, will guide such equilibrium, and continue to serve its several communities around the world. Cheers, Offray On 06/11/16 07:05, stepharo wrote: > Hi > > I would like that you think a bit about our community and that there > is a value in using common tools > > to share and develop common libraries. Because to me it feels like we > are getting balkanize. > > > It may look super cool and be hyper trendy to use github (because like > that you can say that you use latest hyper cool > > features), but I would like to ask especially people building > libraries to pay attention that it is important > > that other people can contribute back easily and that there is an easy > way to load/contribute. > > Today I experienced Bloc > > - I cannot load code and I cannot contribute. > > - I saw mdl with a mixture between smalltalkhub and github (sounds > super hyper cool) and I saw paul not being able to contribute :( > > > Yes you can say that monticello sucks yes it is terrible yes we all > fell like Cobol programmers but at the end of the day. > > Yes the herb is always greener elsewhere. Yes yes yes. Let us take > some facts. > > We managed pharo and moose with it over the last 8 years successfully > and Pharo and moose are not 5 packages together from > > what I can see. So pay attention about the decision you take. > > Now we will provide git support (this is 8 months that nicolas is > exclusively working/thinking/dreaming > > about that) and that we are doing experiments (Guille is managing the > bootstrap in github). > > Now when everybody will have its own little project lost on github (I > do not count the amount of time I do not find pillar on github because > I forget > > that it is called pillar-markup), what will we do. > > So we need an infrastructure to handle this and christophe is working > on this. > > I think that you should consider the accidental complexity as > something that we can minimise by using patterns and common practices. > > Now you can think that I'm an idiot and that I have no vision (be my > guest) but we should pay attention because we are a small community. > > Stef > > > > >

Nov. 6, 2016

Re: [Pharo-users] Pharo desktop UI

by Johan Fabry

Hello Vikenti, I think that you are using the SpecAdapter for morphs in ways it has never been tried or used. So the problems you are having reveal bugs in the SpecAdapter. Please file a bug report, and feel free to contribute a fix as well of course ;-) (more about bugreports here: http://pharo.org/contribute ) -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On 05 Nov 2016, at 21:37, vikenti <vikenti.potapov(a)gmail.com> wrote: > > > New problem with Spec. > > Layout consists of menu and custom control (subclass of Morph created by asSpecAdapter): > initializeWidgets > menu := self instantiate: MenuModel. > self setupMenu. > menu applyTo: self. > locationField := LocationFieldMorph new asSpecAdapter. > > defaultSpec > <spec: #default> > ^ SpecLayout composed > newColumn: > [ :col | > col > add: #menu height: self toolbarHeight; > add: #locationField > ] yourself > > My custom control doesn't automatically resize to fill the area reserved to it by layout spec. > I've tried different existed controls instead of mine but didn't find any solution. Some controls resized (TextModal) some didn't (Morph, BorderedMorph, EllipseMorph). > > I did a dirty hack: in onDraw: of my custom control i set bounds: to aCanvas clipRect and it works fine. > > drawOn: aCanvas > self bounds: aCanvas clipRect . > .... other code .... > > But i think it is a wrong solution and there is somewhere a simple property to setup ( or something like it ). > > Any ideas?

Nov. 6, 2016

Pharo Shared Memory with C++ executable

by Dimitris Chloupis

Hey fellow Pharoers I have great news, I was able to finally !!!! understand how shared memory file works and actually do it Why is that great news you may ask. A shared memory file is a file that maps a specific area of memory, which means when you write to a specific part of the memory it writes directly to the file without you having to actually do this. Memory mapped files have the distinct characteristic of being able to share memory between processes. This actually is the fastest way to make two process communicate and exchange data. Its called Inter Process Communication or IPC for short , but is not technically communication because both executables share the memory. This means that its possible to make Pharo use C++ libraries from inside a C++ executable. Because basically the shared memory will allow Pharo and the C++ executables to share data, part of that data can be messages to execute specific functions. What is super cool about shared memory mapped files is not only that they are super fast(its what the OS uses to load shared libraries ie. DLLs) , its not that it automagically stores the shared memory to disk like a Pharo image (so we can store live data) but foremost that a great deal of programming languages can use Memory Mapped Files which basically means they have wrapped the mmap functions of the LibC library (C/C++ Standard Library). That means we can now use this to make Pharo able to use C++ libraries, python libraries and any library from any programming language. Its also a solution when you dont have access to a DLL or making one is very hard like in my case that I use Unreal Engine. As you can imagine this will replace/extend my socket bridge that I made for python. Of course all the above are no magic, you have to have some basic understanding of how C++ works and how memory mapped files work, funny thing is that shared memory is actually simpler to understand than C++. You also have to make the messaging system and manage the synchronisation. But those are details which I will implement anyway. So my challenge right now is to move this to Pharo. I have done it with C++, I made two different executables which share a string with the value "hello". I need two functions to do this one is open, which is the classic way to open files in C/C++ in my case is #define FILEPATH "mmapped.bin" fd = open(FILEPATH, O_RDWR | O_CREAT | O_TRUNC, (mode_t)0600); https://linux.die.net/man/3/open second one is lseek which expand the size of the file to a desired size result = lseek(fd, FILESIZE-1, SEEK_SET); http://man7.org/linux/man-pages/man2/lseek.2.html the third one is mmap which is doing the actually mapping of the shared memory map =(std::string*) mmap(0, FILESIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); http://man7.org/linux/man-pages/man2/mmap.2.html Now my challenges after reading the UFFI documentation are the following 1) How I can pass things like O_CREAT , MAP_SHARED 2) How I cast a void pointer (its what mmap returns) to a C++ string or C++ int In case you want to take a look at the code is part of a project I named Atlas which can be found here https://github.com/kilon/Atlas The file atlas-server.cpp creates the memory mapped file and writes to the shared memory the string "hello" The file atlas-client.cpp gains access to the shared memory and retrieves the "hello" string Atlas basically will be the library that will give Pharo full access to Unreal internals.

Nov. 6, 2016

Re: [Pharo-users] about balkanisation

by stepharo

Le 6/11/16 Ã 17:21, Stephan Eggermont a Ã©crit : > Kilon wrote: >> If you really want to embrace Github , kill Smalltalkhub > We are not close to doing that. We'll need > Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects. We decided that iceberg will support one way from MC -> github but not the inverse because we do not have the ressources. > > First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside We should be able to manage Pharo with the external projects composing it. Moose Seaside should be working too. So yes this is why guille spent some time building cases and evaluate solutions (submodules vs subtrees vs under one umbrella) with pull requests between subprojects and the rest.... > > Stephan > > > >

Nov. 6, 2016

Re: [Pharo-users] About balkanisation

by stepharo

Le 6/11/16 Ã 17:12, Tudor Girba a Ã©crit : > Hi Stef, > > I think that you are raising a valid point, and I actually agree with it. > > But I think there is another side of the coin as well. > > I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. Yes this what we decided. > To give an example. When the first version of Iceberg was announced, I started to use it for a couple of projects. I stumbled across problems that prevented me from working for several weeks. I could have easily switched to SmalltalkHub, but I did not. I connected with Nicolas and we worked through those problems. Btw, Nicolas is doing a wonderful job, and people should not take this for granted. He tends to be shy, so if you see him around, please give him a hug and let him know that we count on him. Or better yet, use Iceberg for your projects and send him your feedback :). Yes people should try but should pay attention for libraries. > I am sure that there are more problems ahead, and the only way to go through them is committing to go through them. This will push us back for a while, but I really believe in the promise once we get on the other side. I actually think that GitHub is not really a good match for Pharo from a conceptual point of view (the mismatch between what it offers and what we need is quite large), but it is an engineering decision that makes perfect sense for the future. So, yes, we should take GitHub with a grain of salt, and make it a goal to not change much our concept of what makes sense for Pharo. For example, we should not give up on having to resort to the file system. That is why it is so important to make Iceberg (this is not for you Stef because I know you know it, but for others :)). > > And I certainly agree that we should look for sane patterns, but as it goes with patterns, they emerge out of practice. > > I think we should aim for limiting the time of being in between the two worlds. It will not be pleasant, and we can only do it if we stick together and go through it as soon as possible. This why I mentioned that we should pay attention to create different versions > > Cheers, > Doru > > > > >> On Nov 6, 2016, at 1:05 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> I would like that you think a bit about our community and that there is a value in using common tools >> >> to share and develop common libraries. Because to me it feels like we are getting balkanize. >> >> >> It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool >> >> features), but I would like to ask especially people building libraries to pay attention that it is important >> >> that other people can contribute back easily and that there is an easy way to load/contribute. >> >> Today I experienced Bloc >> >> - I cannot load code and I cannot contribute. >> >> - I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :( >> >> >> Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day. >> >> Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts. >> >> We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from >> >> what I can see. So pay attention about the decision you take. >> >> Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming >> >> about that) and that we are doing experiments (Guille is managing the bootstrap in github). >> >> Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget >> >> that it is called pillar-markup), what will we do. >> >> So we need an infrastructure to handle this and christophe is working on this. >> >> I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices. >> >> Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community. >> >> Stef >> >> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling." > > >

Nov. 6, 2016

Re: [Pharo-users] about balkanisation

by Stephan Eggermont

Kilon wrote: > If you really want to embrace Github , kill Smalltalkhub We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects. First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside Stephan

Nov. 6, 2016