- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Pavel Krivanek

2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > > > this mail describes how to start to send pull requests to Pharo 7 Github > > repository from Pharo 7. > > Thank you for the great explanation Pavel. > > > Preparations > > ===================== > > > > - you need to have a Github account and set SSH keys. See > > https://help.github.com/articles/connecting-to-github-with-ssh/ > > - create own pharo-project/pharo repository fork. Go to > > https://github.com/pharo-project/pharo, click on "Fork" button and > follow > > the instructions > > [ ... ] > > > Issue processing > > ===================== > > > > - create new case on FogBugz to get the issue number > > - open Iceberg and from the context menu on the 'pharo' repository do: > Pharo > > - Create new branch from FogBugz issue, enter the issue ID and it will > fill > > the full branch name for you > > - create your changes (you can do it before the creation of the branch > too) > > - commit and push your changes in Iceberg, this way you will commit your > > branch to your fork repository. Remember that the Iceberg commit window > has > > two buttons, one for local commit, the second for commit with immediate > > push. They can be very long because they contain the full branch (issue) > > name > > - in Iceberg in the 'pharo' repository context menu do: Pharo - Create > pull > > request, fill your > > - fill your Github credentials > > - leave the PR title, comment is not required, check the pull request > head > > and base. The base MUST be pharo-project/pharo development. Create the > pull > > requests > > - go to https://github.com/pharo-project/pharo/pulls, check your pull > > requests and put URL of it into the issue record on FogBugz (as a > comment). > > Resolve the issue as Fix review needed > > It means, there is no PR without a corresponding FogBugz issue ? > Yes, at least for code changes we would like to keep this relation. If it is a really trivial change in readme or something like that, we can accept no related issue record. Please prefer to comment the issues instead of PRs directly to have all information at one place. Cheers, -- Pavel > Regards, > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

June 27, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Esteban Lorenzano

> On 27 Jun 2017, at 15:57, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> this mail describes how to start to send pull requests to Pharo 7 Github >> repository from Pharo 7. > > Thank you for the great explanation Pavel. > >> Preparations >> ===================== >> >> - you need to have a Github account and set SSH keys. See >> https://help.github.com/articles/connecting-to-github-with-ssh/ >> - create own pharo-project/pharo repository fork. Go to >> https://github.com/pharo-project/pharo, click on "Fork" button and follow >> the instructions > > [ ... ] > >> Issue processing >> ===================== >> >> - create new case on FogBugz to get the issue number >> - open Iceberg and from the context menu on the 'pharo' repository do: Pharo >> - Create new branch from FogBugz issue, enter the issue ID and it will fill >> the full branch name for you >> - create your changes (you can do it before the creation of the branch too) >> - commit and push your changes in Iceberg, this way you will commit your >> branch to your fork repository. Remember that the Iceberg commit window has >> two buttons, one for local commit, the second for commit with immediate >> push. They can be very long because they contain the full branch (issue) >> name >> - in Iceberg in the 'pharo' repository context menu do: Pharo - Create pull >> request, fill your >> - fill your Github credentials >> - leave the PR title, comment is not required, check the pull request head >> and base. The base MUST be pharo-project/pharo development. Create the pull >> requests >> - go to https://github.com/pharo-project/pharo/pulls, check your pull >> requests and put URL of it into the issue record on FogBugz (as a comment). >> Resolve the issue as Fix review needed > > It means, there is no PR without a corresponding FogBugz issue ? it should not. same as before with SLICEs, there was no slice without issue :) Esteban > > Regards, > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

June 27, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Serge Stinckwich

On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > this mail describes how to start to send pull requests to Pharo 7 Github > repository from Pharo 7. Thank you for the great explanation Pavel. > Preparations > ===================== > > - you need to have a Github account and set SSH keys. See > https://help.github.com/articles/connecting-to-github-with-ssh/ > - create own pharo-project/pharo repository fork. Go to > https://github.com/pharo-project/pharo, click on "Fork" button and follow > the instructions [ ... ] > Issue processing > ===================== > > - create new case on FogBugz to get the issue number > - open Iceberg and from the context menu on the 'pharo' repository do: Pharo > - Create new branch from FogBugz issue, enter the issue ID and it will fill > the full branch name for you > - create your changes (you can do it before the creation of the branch too) > - commit and push your changes in Iceberg, this way you will commit your > branch to your fork repository. Remember that the Iceberg commit window has > two buttons, one for local commit, the second for commit with immediate > push. They can be very long because they contain the full branch (issue) > name > - in Iceberg in the 'pharo' repository context menu do: Pharo - Create pull > request, fill your > - fill your Github credentials > - leave the PR title, comment is not required, check the pull request head > and base. The base MUST be pharo-project/pharo development. Create the pull > requests > - go to https://github.com/pharo-project/pharo/pulls, check your pull > requests and put URL of it into the issue record on FogBugz (as a comment). > Resolve the issue as Fix review needed It means, there is no PR without a corresponding FogBugz issue ? Regards, -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Pavel Krivanek

Besides several TBehavior-like traits with more than one user in the kernel (TApplyingOnClassSide TBehavior TClass TClassDescription TComposingDescription) we have some more general ones (TSortable TTranscript). So we will have some code duplicities. -- Pavel 2017-06-27 15:13 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > But that's not the case. The only usage of traits in the Kernel is > TBehaviour, to share some common behaviour between traits and classes. But > Pablo is working on a new modular implementation of traits that would not > require TBehavior, and would simplify the code of classes. > > On Tue, Jun 27, 2017 at 3:04 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> > wrote: > >> >> El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> escribiÃ³: >> >> >> >> 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: >> >>> Just for curiosity: Is it a good decision? It is supposed that with >>> Traits we can have less code duplication. And maybe the code duplication >>> happens also in the Pharo kernel, right? >>> >>> Thanks for any explanation :-) >>> >> >> You are right, it will cause more code duplicities in the kernel. On the >> other hand we will be able to clean the traits implementation and make it >> more modular, so the users will have more options like stateful traits, >> talents etc. We needed to do a small step back to be able to move forward. >> It was not an easy decision but it was planned for a long time. And in >> the end, this decision was done by people who introduced traits and >> invested a lot of time and effort into them. >> >> >> Thatâs interesting. Thanks for the explanation :-) >> >> Juraj >> >> >> -- Pavel >> >> >> >>> >>> Cheers, >>> Juraj >>> >>> > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> escribiÃ³: >>> > >>> > Hi, >>> > >>> > because we want to have traits only as an option where people will be >>> able to choose custom traits implementation, the Pharo kernel cannot depend >>> on them. For that reason we had to flatten all classes that use traits in >>> the kernel packages. >>> > That means that methods from system traits as TBehavior [1] were >>> copied to the trait users and the traits were removed from the class >>> definitions. For now these traits are still present in the image. >>> > If you use own traits in your projects, this step will have no impact >>> on you. Only if your project extends the system traits, you will need to >>> adopt it for Pharo 7. >>> > >>> > [1] complete list: TApplyingOnClassSide TBehavior >>> TBehaviorCategorization TClass TClassDescription TComposingDescription >>> TSortable TTranscript TTransformationCompatibility >>> > >>> > Cheers, >>> > -- Pavel >>> >>> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > 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 <+33%206%2052%2070%2066%2013> >

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Guillermo Polito

But that's not the case. The only usage of traits in the Kernel is TBehaviour, to share some common behaviour between traits and classes. But Pablo is working on a new modular implementation of traits that would not require TBehavior, and would simplify the code of classes. On Tue, Jun 27, 2017 at 3:04 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: > > > > 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > >> Just for curiosity: Is it a good decision? It is supposed that with >> Traits we can have less code duplication. And maybe the code duplication >> happens also in the Pharo kernel, right? >> >> Thanks for any explanation :-) >> > > You are right, it will cause more code duplicities in the kernel. On the > other hand we will be able to clean the traits implementation and make it > more modular, so the users will have more options like stateful traits, > talents etc. We needed to do a small step back to be able to move forward. > It was not an easy decision but it was planned for a long time. And in the > end, this decision was done by people who introduced traits and invested a > lot of time and effort into them. > > > Thatâs interesting. Thanks for the explanation :-) > > Juraj > > > -- Pavel > > > >> >> Cheers, >> Juraj >> >> > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> escribiÃ³: >> > >> > Hi, >> > >> > because we want to have traits only as an option where people will be >> able to choose custom traits implementation, the Pharo kernel cannot depend >> on them. For that reason we had to flatten all classes that use traits in >> the kernel packages. >> > That means that methods from system traits as TBehavior [1] were copied >> to the trait users and the traits were removed from the class definitions. >> For now these traits are still present in the image. >> > If you use own traits in your projects, this step will have no impact >> on you. Only if your project extends the system traits, you will need to >> adopt it for Pharo 7. >> > >> > [1] complete list: TApplyingOnClassSide TBehavior >> TBehaviorCategorization TClass TClassDescription TComposingDescription >> TSortable TTranscript TTransformationCompatibility >> > >> > Cheers, >> > -- Pavel >> >> >> > > -- Guille Polito Research Engineer 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

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Tudor Girba

Great contribution! Doru > On Jun 27, 2017, at 2:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. > > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Juraj Kubelka

> El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > > > > 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>>: > Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right? > > Thanks for any explanation :-) > > You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward. > It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them. Thatâs interesting. Thanks for the explanation :-) Juraj > > -- Pavel > > > > Cheers, > Juraj > > > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> escribiÃ³: > > > > Hi, > > > > because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages. > > That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image. > > If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7. > > > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility > > > > Cheers, > > -- Pavel > > >

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by phil＠highoctane.be

Wow. Phil On Tue, Jun 27, 2017 at 2:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] > and later), implementing the simple query cycle. It supports plaintext and > md5 password authentication as well as SSL connections. When SQL queries > return row data, incoming data is efficiently converted to objects. > P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced > object-relational mapper, and P3Client, most Glorp unit tests pass (the > same number as the older, proven PostgresV2 driver, that is using the > legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world > testing before it is ready for general release. > > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser > and it was a beautiful & satisfying experience. Thank you Denis, well done > ! I also used Iceberg a second time and it starts to feel natural to me. > Thank you Nico and Esteban ! > > >

June 27, 2017

[ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Sven Van Caekenberghe

P3 is a modern, lean and mean PostgreSQL client for Pharo. P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. More info, usage examples and code at https://github.com/svenvc/P3 P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. Sven PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban !

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Pavel Krivanek

2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Just for curiosity: Is it a good decision? It is supposed that with Traits > we can have less code duplication. And maybe the code duplication happens > also in the Pharo kernel, right? > > Thanks for any explanation :-) > You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward. It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them. -- Pavel > > Cheers, > Juraj > > > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: > > > > Hi, > > > > because we want to have traits only as an option where people will be > able to choose custom traits implementation, the Pharo kernel cannot depend > on them. For that reason we had to flatten all classes that use traits in > the kernel packages. > > That means that methods from system traits as TBehavior [1] were copied > to the trait users and the traits were removed from the class definitions. > For now these traits are still present in the image. > > If you use own traits in your projects, this step will have no impact on > you. Only if your project extends the system traits, you will need to adopt > it for Pharo 7. > > > > [1] complete list: TApplyingOnClassSide TBehavior > TBehaviorCategorization TClass TClassDescription TComposingDescription > TSortable TTranscript TTransformationCompatibility > > > > Cheers, > > -- Pavel > > >

June 27, 2017