- Pharo-users - lists.pharo.org

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by Stephane Ducasse

Diego I recently restarted to edit a booklet for Magritte. It would be nice if we can join forces. https://github.com/SquareBracketAssociates/Booklet-Magritte On Fri, Sep 22, 2017 at 1:27 PM, Diego Lont <diego.lont(a)delware.nl> wrote: > There is actually a tutorial included in the framework itself. One you have > it loaded, you can start the webpage to localhost:8080 and there you have > your tutorial. But this tutorial should be on a external webpage â¦ one of > the things on my todo list. > > On 22 Sep 2017, at 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > On 9/18/17, laurent <laurent.laffont(a)gmail.com> wrote: > > Hi all, > > it's been a long time :) At work we are currently comparing several > technologies to start a business project that will hopefully be used by > thousands of people for several years ;) > > We need a web stack and we put Pharo & co in the comparative process. > My team have strong experience in load-balanced php / mysql deployment > that handles millions of records but we are ready to build on > something else though MySQL is still a requirement. > > Thanks for Garage + Glorp, I can prototype things. I wonder how to > handle database schema migrations. With our PHP projects we have > versionned PHP scripts that are automatically run given a database > revision number ( see > http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). > What are the practices with Glorp ? > > > We try QCMagritte and we enjoy what we see so far. What are the best > practices to glue Magritte and Glorp together ? Especially when you > load-balance requests on several images. Some examples ? > > ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable > version, MADescriptionBuilder missing. For #development versions of > Magritte and QCMagritte, QCConfiguration missing ). So actually I use > the one built on CI. ) > > > May be you have some other suggestions on a framework you love ? > > > Maybe you have a look as well at > https://railsexpress.quora.com/Pharo-Seaside-Express > (referenced in another thread). > > Use Smalltalk as modeling / design tool and generator. Then the run > time is done with another technology. > > > Best regards, > > Laurent Laffont > >

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by Stephane Ducasse

Laurent do you need that we send someone to your place to help? Stef On Fri, Sep 22, 2017 at 10:28 AM, laurent <laurent.laffont(a)gmail.com> wrote: > Hi Stephan, > > actually the difficult part is how to manage correctly Glorp > sessions/connections and update of objects in database. My team is quite sad > because QCMagritte and Glorp looks nice but we lack experience glueing both > together and could not find any documentation on the subject. > > Laurent > > > Le mer. 20 sept. 2017 Ã 11:53, stephan <stephan(a)stack.nl> a Ã©crit : > > On 18-09-17 12:22, laurent wrote: > > We try QCMagritte and we enjoy what we see so far. What are the best > practices to glue Magritte and Glorp together ? Especially when you > load-balance requests on several images. Some examples ? ( FYI, I cannot > load QCMagritte in a fresh Pharo 6 image ( for #stable version, > MADescriptionBuilder missing. For #development versions of Magritte and > QCMagritte, QCConfiguration missing ). So actually I use the one built on > CI. ) > > I really like describing domain objects with Magritte and using chains of > visitors to add cross-cutting concerns like translations, styling and access > control. The resulting domain code is very clean and DRY. To map to > database/Glorp I would just add properties to the description wherever > needed, and add a visitor creating the mappings. We didn't need that as we > developed in Pharo and deployed on Gemstone. At the moment QC generates > applications using jQuery, and the live updating needs a round-trip to the > server. You might want to substitute that with something that does more > client side. I haven't looked in detail at what Johan Brichau is doing. An > open issue is live updates that update each other. That needs automatically > calculating dependencies and update order. I've copied the latest > configuration and added #'pharo6.x' but that is not enough. Stephan

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by Diego Lont

The repository can be found on smalltalk hub. Here are also load instruction: http://smalltalkhub.com/#!/~DiegoLont/QCMagritte/ I just checked loading in pharo 6 (after making a fix) of: Gofer new url: 'http://smalltalkhub.com/mc/DiegoLont/QCMagritte/main'; package: 'ConfigurationOfQCMagritte'; load. ((Smalltalk at: #ConfigurationOfQCMagritte) project version: #'development') load. (Smalltalk at: #ZnZincServerAdaptor) startOn: 8080 And this allows me to start the tutorial. It seems not all versions load yet, so I need to do some more work on the configuration, but this will be next week. Regards, Diego P.S. QC stands for the company it was originally build for. I do not know exactly where the initials stand for â¦ as it was already an historic name at that time. > On 22 Sep 2017, at 13:35, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > On 9/22/17, Diego Lont <diego.lont(a)delware.nl <mailto:diego.lont@delware.nl>> wrote: >> There is actually a tutorial included in the framework itself. > > Great! > >> One you have >> it loaded, you can start the webpage to localhost:8080 and there you have >> your tutorial. But this tutorial should be on a external webpage â¦ one of >> the things on my todo list. > > No problem if the tutorial is included in the framework. I just need to know. > > Where is the repository of QCMagritte? > > >>> On 22 Sep 2017, at 12:55, H. Hirzel <hannes.hirzel(a)gmail.com <mailto:hannes.hirzel@gmail.com>> wrote: >>> >>> On 9/18/17, laurent <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com> >>> <mailto:laurent.laffont@gmail.com <mailto:laurent.laffont@gmail.com>>> wrote: >>>> Hi all, >>>> >>>> it's been a long time :) At work we are currently comparing several >>>> technologies to start a business project that will hopefully be used by >>>> thousands of people for several years ;) >>>> >>>> We need a web stack and we put Pharo & co in the comparative process. >>>> My team have strong experience in load-balanced php / mysql deployment >>>> that handles millions of records but we are ready to build on >>>> something else though MySQL is still a requirement. >>>> >>>> Thanks for Garage + Glorp, I can prototype things. I wonder how to >>>> handle database schema migrations. With our PHP projects we have >>>> versionned PHP scripts that are automatically run given a database >>>> revision number ( see >>>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). >>>> What are the practices with Glorp ? >>>> >>>> >>>> We try QCMagritte and we enjoy what we see so far. What are the best >>>> practices to glue Magritte and Glorp together ? Especially when you >>>> load-balance requests on several images. Some examples ? >>>> >>>> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable >>>> version, MADescriptionBuilder missing. For #development versions of >>>> Magritte and QCMagritte, QCConfiguration missing ). So actually I use >>>> the one built on CI. ) >>>> >>>> >>>> May be you have some other suggestions on a framework you love ? >>> >>> Maybe you have a look as well at >>> https://railsexpress.quora.com/Pharo-Seaside-Express <https://railsexpress.quora.com/Pharo-Seaside-Express> >>> <https://railsexpress.quora.com/Pharo-Seaside-Express <https://railsexpress.quora.com/Pharo-Seaside-Express>> >>> (referenced in another thread). >>> >>> Use Smalltalk as modeling / design tool and generator. Then the run >>> time is done with another technology. >>> >>>> >>>> Best regards, >>>> >>>> Laurent Laffont

Sept. 22, 2017

X11 options on Ubuntu VM / Athens rendering problems

by J.F. Rick

I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed. In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run: ./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE & Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect. Any suggestions? Jeff

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by H. Hirzel

On 9/22/17, Diego Lont <diego.lont(a)delware.nl> wrote: > There is actually a tutorial included in the framework itself. Great! >One you have > it loaded, you can start the webpage to localhost:8080 and there you have > your tutorial. But this tutorial should be on a external webpage â¦ one of > the things on my todo list. No problem if the tutorial is included in the framework. I just need to know. Where is the repository of QCMagritte? >> On 22 Sep 2017, at 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> >> On 9/18/17, laurent <laurent.laffont(a)gmail.com >> <mailto:laurent.laffont@gmail.com>> wrote: >>> Hi all, >>> >>> it's been a long time :) At work we are currently comparing several >>> technologies to start a business project that will hopefully be used by >>> thousands of people for several years ;) >>> >>> We need a web stack and we put Pharo & co in the comparative process. >>> My team have strong experience in load-balanced php / mysql deployment >>> that handles millions of records but we are ready to build on >>> something else though MySQL is still a requirement. >>> >>> Thanks for Garage + Glorp, I can prototype things. I wonder how to >>> handle database schema migrations. With our PHP projects we have >>> versionned PHP scripts that are automatically run given a database >>> revision number ( see >>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). >>> What are the practices with Glorp ? >>> >>> >>> We try QCMagritte and we enjoy what we see so far. What are the best >>> practices to glue Magritte and Glorp together ? Especially when you >>> load-balance requests on several images. Some examples ? >>> >>> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable >>> version, MADescriptionBuilder missing. For #development versions of >>> Magritte and QCMagritte, QCConfiguration missing ). So actually I use >>> the one built on CI. ) >>> >>> >>> May be you have some other suggestions on a framework you love ? >> >> Maybe you have a look as well at >> https://railsexpress.quora.com/Pharo-Seaside-Express >> <https://railsexpress.quora.com/Pharo-Seaside-Express> >> (referenced in another thread). >> >> Use Smalltalk as modeling / design tool and generator. Then the run >> time is done with another technology. >> >>> >>> Best regards, >>> >>> Laurent Laffont > >

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by Diego Lont

There is actually a tutorial included in the framework itself. One you have it loaded, you can start the webpage to localhost:8080 and there you have your tutorial. But this tutorial should be on a external webpage â¦ one of the things on my todo list. > On 22 Sep 2017, at 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > On 9/18/17, laurent <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: >> Hi all, >> >> it's been a long time :) At work we are currently comparing several >> technologies to start a business project that will hopefully be used by >> thousands of people for several years ;) >> >> We need a web stack and we put Pharo & co in the comparative process. >> My team have strong experience in load-balanced php / mysql deployment >> that handles millions of records but we are ready to build on >> something else though MySQL is still a requirement. >> >> Thanks for Garage + Glorp, I can prototype things. I wonder how to >> handle database schema migrations. With our PHP projects we have >> versionned PHP scripts that are automatically run given a database >> revision number ( see >> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). >> What are the practices with Glorp ? >> >> >> We try QCMagritte and we enjoy what we see so far. What are the best >> practices to glue Magritte and Glorp together ? Especially when you >> load-balance requests on several images. Some examples ? >> >> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable >> version, MADescriptionBuilder missing. For #development versions of >> Magritte and QCMagritte, QCConfiguration missing ). So actually I use >> the one built on CI. ) >> >> >> May be you have some other suggestions on a framework you love ? > > Maybe you have a look as well at > https://railsexpress.quora.com/Pharo-Seaside-Express <https://railsexpress.quora.com/Pharo-Seaside-Express> > (referenced in another thread). > > Use Smalltalk as modeling / design tool and generator. Then the run > time is done with another technology. > >> >> Best regards, >> >> Laurent Laffont

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by H. Hirzel

On 9/18/17, laurent <laurent.laffont(a)gmail.com> wrote: > Hi all, > > it's been a long time :) At work we are currently comparing several > technologies to start a business project that will hopefully be used by > thousands of people for several years ;) > > We need a web stack and we put Pharo & co in the comparative process. > My team have strong experience in load-balanced php / mysql deployment > that handles millions of records but we are ready to build on > something else though MySQL is still a requirement. > > Thanks for Garage + Glorp, I can prototype things. I wonder how to > handle database schema migrations. With our PHP projects we have > versionned PHP scripts that are automatically run given a database > revision number ( see > http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). > What are the practices with Glorp ? > > > We try QCMagritte and we enjoy what we see so far. What are the best > practices to glue Magritte and Glorp together ? Especially when you > load-balance requests on several images. Some examples ? > > ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable > version, MADescriptionBuilder missing. For #development versions of > Magritte and QCMagritte, QCConfiguration missing ). So actually I use > the one built on CI. ) > > > May be you have some other suggestions on a framework you love ? Maybe you have a look as well at https://railsexpress.quora.com/Pharo-Seaside-Express (referenced in another thread). Use Smalltalk as modeling / design tool and generator. Then the run time is done with another technology. > > Best regards, > > Laurent Laffont > > > > > > >

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by H. Hirzel

Hello Diego What does QC in QCMagritte stand for? I understand that QCMagritte is an application framework on top of Seaside and Magritte. I found this presentation https://www.slideshare.net/esug/getting-started-with-qcmagritte Is there a home page with more information? Regards Hannes On 9/22/17, Diego Lont <diego.lont(a)delware.nl> wrote: > Hi Laurent, > > I am happy that you like QCMagritte. I wrote quite some parts of it, but it > also has been a while since I last used it. I try to support it in my spare > time, so I will look into the issue that prevents it from loading into pharo > 6. > > Here some ideas that I think of, > > QCMagritte is a stack based on Seaside and Magritte. So you have a choice > wether you connect Glorp to the session management of Seaside (like Gemstone > does, I do not know exactly) or to the update mechanism of Magritte. > > This updating of the object is done in the memento. You can give your > objects a custom memento class and override here the pull // push methods > that update your model. It actually has a commit method that commits the > changes into the object. > > Note the QCMagritte already has a custom memento class, for the AJAX > liveness, so I suggest subclassing QCAjaxMemento. > > Of course, you need to do something in case of a changed object, since you > plan on running multiple images, so perhaps on validating the object (also > controlled by the memento), you want to give some error messages, forcing > the user to reload before committing his changes. > > I do not know if implementing this into the mementoâs gives you proper > performance, as potentially multiple objects are updated by one user > action. > > Regards, > Diego > >> On 22 Sep 2017, at 10:28, laurent <laurent.laffont(a)gmail.com> wrote: >> >> Hi Stephan, >> >> actually the difficult part is how to manage correctly Glorp >> sessions/connections and update of objects in database. My team is quite >> sad because QCMagritte and Glorp looks nice but we lack experience glueing >> both together and could not find any documentation on the subject. >> >> Laurent >> >> Le mer. 20 sept. 2017 Ã 11:53, stephan <stephan(a)stack.nl> a Ã©crit : >>> On 18-09-17 12:22, laurent wrote: >>> We try QCMagritte and we enjoy what we see so far. What are the best >>> practices to glue Magritte and Glorp together ? Especially when you >>> load-balance requests on several images. Some examples ? >>> >>> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable >>> version, MADescriptionBuilder missing. For #development versions of >>> Magritte and QCMagritte, QCConfiguration missing ). So actually I use the >>> one built on CI. ) >>> >>> I really like describing domain objects with Magritte and using chains of >>> visitors to add cross-cutting concerns like translations, styling and >>> access control. The resulting domain code is very clean and DRY. To map >>> to database/Glorp I would just add properties to the description wherever >>> needed, and add a visitor creating the mappings. We didn't need that as >>> we developed in Pharo and deployed on Gemstone. >>> >>> At the moment QC generates applications using jQuery, and the live >>> updating needs a round-trip to the server. You might want to substitute >>> that with something that does more client side. I haven't looked in >>> detail at what Johan Brichau is doing. >>> >>> An open issue is live updates that update each other. That needs >>> automatically calculating dependencies and update order. >>> >>> I've copied the latest configuration and added #'pharo6.x' but that is >>> not enough. >>> >>> Stephan >>> > >

Sept. 22, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by Diego Lont

Hi Laurent, I am happy that you like QCMagritte. I wrote quite some parts of it, but it also has been a while since I last used it. I try to support it in my spare time, so I will look into the issue that prevents it from loading into pharo 6. Here some ideas that I think of, QCMagritte is a stack based on Seaside and Magritte. So you have a choice wether you connect Glorp to the session management of Seaside (like Gemstone does, I do not know exactly) or to the update mechanism of Magritte. This updating of the object is done in the memento. You can give your objects a custom memento class and override here the pull // push methods that update your model. It actually has a commit method that commits the changes into the object. Note the QCMagritte already has a custom memento class, for the AJAX liveness, so I suggest subclassing QCAjaxMemento. Of course, you need to do something in case of a changed object, since you plan on running multiple images, so perhaps on validating the object (also controlled by the memento), you want to give some error messages, forcing the user to reload before committing his changes. I do not know if implementing this into the mementoâs gives you proper performance, as potentially multiple objects are updated by one user action. Regards, Diego > On 22 Sep 2017, at 10:28, laurent <laurent.laffont(a)gmail.com> wrote: > > Hi Stephan, > > actually the difficult part is how to manage correctly Glorp sessions/connections and update of objects in database. My team is quite sad because QCMagritte and Glorp looks nice but we lack experience glueing both together and could not find any documentation on the subject. > > Laurent > > Le mer. 20 sept. 2017 Ã 11:53, stephan <stephan(a)stack.nl> a Ã©crit : >> On 18-09-17 12:22, laurent wrote: >> We try QCMagritte and we enjoy what we see so far. What are the best practices to glue Magritte and Glorp together ? Especially when you load-balance requests on several images. Some examples ? >> >> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable version, MADescriptionBuilder missing. For #development versions of Magritte and QCMagritte, QCConfiguration missing ). So actually I use the one built on CI. ) >> >> I really like describing domain objects with Magritte and using chains of visitors to add cross-cutting concerns like translations, styling and access control. The resulting domain code is very clean and DRY. To map to database/Glorp I would just add properties to the description wherever needed, and add a visitor creating the mappings. We didn't need that as we developed in Pharo and deployed on Gemstone. >> >> At the moment QC generates applications using jQuery, and the live updating needs a round-trip to the server. You might want to substitute that with something that does more client side. I haven't looked in detail at what Johan Brichau is doing. >> >> An open issue is live updates that update each other. That needs automatically calculating dependencies and update order. >> >> I've copied the latest configuration and added #'pharo6.x' but that is not enough. >> >> Stephan >>

Sept. 22, 2017

Re: [Pharo-users] Pharo 7 license question

by Jose San Leandro

+1 to "recursive" 2017-09-22 11:05 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > I am just stating the neutral term to describe GPL license nature is > "recursive", and why it was designed as this. The "viral" term is > unnecessary emotionally charged. > > I don't fell the discussion turned about MIT vs GPL, Pharo been MIT is > just fine. > > Hilaire > > Le 22/09/2017 Ã 10:40, Thierry Goubier a Ã©crit : > >> >> The appropriate and neutral term to describe GPL licence is >> "recursive". >> >> GPL licence was designed to build a better computing community, >> where freedom is 1st consideration, even at the expense of a lower >> acceptance. >> >> >> And the little technical fact that you can't link code in the Smalltalk >> world, only create a derivative work, has nothing to do with the community >> stance on MIT versus GPL. >> >> > -- > Dr. Geo > http://drgeo.eu > > > >

Sept. 22, 2017