April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

by Cameron Sanders

Magritte could be improved to allow a context of usage to be specified e.g. #tableReport, or #editor, and then allow class designers to specify the pairs of keys for CSS style to be written for the context. We'll follow up on this point soon. Seaside could accept more renderingBlocks to be more customizable. And/or Magritte descriptions should allow these to be passed down. But where does one draw the line? Like the above paragraph on CSS, different contexts demand different rendering blocks. So in fact, we pull together our Magritte descriptions in non-standard ways for our most important view: the portfolio browser. Many are created dynamically from accounting terms in a DB, because there are thousands of possible rules/equations, and they cannot all be hand-coded for this one class. - In our application, Magritte provides a mechanism to describe the attributes (or computed terms) in order to paint an editor, a read-only view, and/or table presentation/edit dialogs. For complex specification and controller classes, we often still need to write dedicated Components. We do not use Magritte for persistence, instead we use a variant of DebrisDB that works on Gemstone & Pharo. So our CRUD solution involves our own tables (seaside subclasses) that allow us to install blocks to implement various behaviors such as "update table from DB". We also allow application-level "plugin" rules to be presented as buttons and controls, but these are very specific to our whole framework. The launching of these tables is handled through various of our own constructs, specifically our ApplicationContext, which knows where to put new panes/components, for example. Much of the speed with which we can define a new class, have it persistent (no time using DebrisDB), and have editors/presenters (perhaps 1 to 15 minutes per instVar for simple classes), is due to the culmination of various tools in our environment and our experience with such. -Cam On Tue, Apr 21, 2015 at 2:55 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 21/4/15 18:26, Mariano Martinez Peck a Ã©crit : > > Hi Stef, > > Similar to what Yanni said, 99% of our extensions are to > Magritte-Seaside, not to magritte core itself. I honestly see Magritte as a > very small and super extensible framework from which you can build your own > on top of it. Like QCMagritte. Or likely what Yanni did, or likely what we > did. That is...a set of subclasses/extensions to Magritte Seaside. This > doesn't mean we shouldn't make this open-source, but I am just saying all > our extensions should not be Magritte core code but kind of a framework > build on top of Magritte core. > > Just to give you an idea of the extensibility of Magritte... is that > with all our framework build on top of Magritte, we had NO OVERRIDE and our > classes/extensions load cleanly after loading Magritte. > > > Ok I trust you. So this is good. > > Now I do not know how to do crud applications with magritte. > > > Cheers, > > > On Sat, Apr 18, 2015 at 4:55 PM, stepharo <stepharo(a)free.fr> wrote: > >> And BTW I would really like to see how we can do crude with >> magritte-described objects. >> >> >> Le 18/4/15 21:37, stepharo a Ã©crit : >> >> >>> >>> Le 18/4/15 20:04, Yanni Chiu a Ã©crit : >>> >>>> On Apr 18, 2015, at 2:18 AM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> I found strange that not a single little improvements of Magritte was >>>>> necessary for the Qude project. >>>>> >>>> Itâs not strange to me, because when working with Magritte 2, it seemed >>>> that almost everything I wanted to do had a hook method to override, or an >>>> obvious place to subclass or extend. So much so, that when I could not find >>>> the extension point, I thought it was my fault. What was missing was >>>> instance-based descriptions, which was added by the community in Magritte 3. >>>> >>> >>> :) >>> >>> >>>> Given how well-factored Magritte 2 was, my deduction was that a lot of >>>> effort had already been done to extract out an open-source artefact, from >>>> whatever system drove itâs development. So, no surprise that few >>>> improvements to the core Magritte were needed. >>>> >>> >>> Ok so we have perfect software. Good to know. >>> >>>> Now if heavy users of open-source libraries do not enhance these >>>>> open-source libraries and keep their extensions >>>>> under close source then the open-source libraries will never make >>>>> progress and I will immensely sad. >>>>> >>>> Given that Magritte is already well-factored for extensions, what tends >>>> to be written is exactly the custom code which you would not be releasing >>>> to open-source. >>>> >>> >>> but you see I did not use magritte since long time. It would be great to >>> have example of custom-code. >>> For example are relationships any useful. >>> >>>> >>>> However, there might be a case for add-ons, such as Twitter Bootstrap >>>> support. As mentioned in another post, changing the Magritte API/interfaces >>>> at this point is tricky, because it would affect current users - thatâs the >>>> conundrum: success and wider adoption will constrain the evolution. >>>> >>> We have versions to help there. >>> >>> The addition of instance-based descriptions was worth the (minor) pain >>>> of the transition, but what level of pain would be tolerable to add >>>> Bootstrap support, especially if youâre not using Bootstrap. >>>> >>> But we are talking about SeasideMagritte here? >>> I do not know because I do not have experience. >>> I was talking about magritte. >>> >>> >>> >>> >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > >

April 21, 2015

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

by stepharo

Le 21/4/15 18:26, Mariano Martinez Peck a Ã©crit : > Hi Stef, > > Similar to what Yanni said, 99% of our extensions are to > Magritte-Seaside, not to magritte core itself. I honestly see Magritte > as a very small and super extensible framework from which you can > build your own on top of it. Like QCMagritte. Or likely what Yanni > did, or likely what we did. That is...a set of subclasses/extensions > to Magritte Seaside. This doesn't mean we shouldn't make this > open-source, but I am just saying all our extensions should not be > Magritte core code but kind of a framework build on top of Magritte core. > > Just to give you an idea of the extensibility of Magritte... is that > with all our framework build on top of Magritte, we had NO OVERRIDE > and our classes/extensions load cleanly after loading Magritte. Ok I trust you. So this is good. Now I do not know how to do crud applications with magritte. > > Cheers, > > On Sat, Apr 18, 2015 at 4:55 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > And BTW I would really like to see how we can do crude with > magritte-described objects. > > > Le 18/4/15 21:37, stepharo a Ã©crit : > > > > Le 18/4/15 20:04, Yanni Chiu a Ã©crit : > > On Apr 18, 2015, at 2:18 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > I found strange that not a single little improvements > of Magritte was necessary for the Qude project. > > Itâs not strange to me, because when working with Magritte > 2, it seemed that almost everything I wanted to do had a > hook method to override, or an obvious place to subclass > or extend. So much so, that when I could not find the > extension point, I thought it was my fault. What was > missing was instance-based descriptions, which was added > by the community in Magritte 3. > > > :) > > > Given how well-factored Magritte 2 was, my deduction was > that a lot of effort had already been done to extract out > an open-source artefact, from whatever system drove itâs > development. So, no surprise that few improvements to the > core Magritte were needed. > > > Ok so we have perfect software. Good to know. > > Now if heavy users of open-source libraries do not > enhance these open-source libraries and keep their > extensions > under close source then the open-source libraries will > never make progress and I will immensely sad. > > Given that Magritte is already well-factored for > extensions, what tends to be written is exactly the custom > code which you would not be releasing to open-source. > > > but you see I did not use magritte since long time. It would > be great to have example of custom-code. > For example are relationships any useful. > > > However, there might be a case for add-ons, such as > Twitter Bootstrap support. As mentioned in another post, > changing the Magritte API/interfaces at this point is > tricky, because it would affect current users - thatâs the > conundrum: success and wider adoption will constrain the > evolution. > > We have versions to help there. > > The addition of instance-based descriptions was worth the > (minor) pain of the transition, but what level of pain > would be tolerable to add Bootstrap support, especially if > youâre not using Bootstrap. > > But we are talking about SeasideMagritte here? > I do not know because I do not have experience. > I was talking about magritte. > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

April 21, 2015

Re: [Pharo-users] deploying a desktop GUI based image

by Hilaire

Hi Sebastian, You may want to look at the DrGeo desktop application. There is no documentation but you can dig in the DrGeoInstaller class[1] and the shell build script[2] [1] http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo [2] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/build/ Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

April 21, 2015

Re: [Pharo-users] Time traveling Pharo

by Johan Fabry

Time travel is not a bug, itâs a feature! ;-) https://pharo.fogbugz.com/f/cases/15376/Pharo-4-0-sais-it-s-5-0-in-the-abou… > On Apr 21, 2015, at 14:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > This is not correctâ¦ can you enter an issue? > >> On 21 Apr 2015, at 19:07, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >> Hi all, >> >> finally having some time to develop again, I downloaded the 4.0 image sources and vm (http://files.pharo.org/get-files/40/pharo.zip et cetera) through the links on the downloads page. >> >> Itâs a bit strange that the image version is 5000, but OK I can understand it. More funny is the time traveling behavior that occurs when doing World->System->About. It says: >> >> Pharo5.0 >> Latest update: #50000 >> >> [â¦] >> >> Time-traveling from next year back to today! Wow! :-P >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

April 21, 2015

Re: [Pharo-users] Time traveling Pharo

by Marcus Denker

This is not correctâ¦ can you enter an issue? > On 21 Apr 2015, at 19:07, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > Hi all, > > finally having some time to develop again, I downloaded the 4.0 image sources and vm (http://files.pharo.org/get-files/40/pharo.zip et cetera) through the links on the downloads page. > > Itâs a bit strange that the image version is 5000, but OK I can understand it. More funny is the time traveling behavior that occurs when doing World->System->About. It says: > > Pharo5.0 > Latest update: #50000 > > [â¦] > > Time-traveling from next year back to today! Wow! :-P > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

April 21, 2015

Time traveling Pharo

by Johan Fabry

Hi all, finally having some time to develop again, I downloaded the 4.0 image sources and vm (http://files.pharo.org/get-files/40/pharo.zip et cetera) through the links on the downloads page. Itâs a bit strange that the image version is 5000, but OK I can understand it. More funny is the time traveling behavior that occurs when doing World->System->About. It says: Pharo5.0 Latest update: #50000 [â¦] Time-traveling from next year back to today! Wow! :-P ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

April 21, 2015

Re: [Pharo-users] Wrong slave for CI job

by Blondeau Vincent

Indeed, but it seems that is not the main problem. As you use a configuration matrix, you should go inside one "cell" to see the real problem. For example, go to: https://ci.inria.fr/pharo-contribution/job/Cormas/PHARO=40,VERSION=developm… You will see that the job tries to access: http://smalltalkhub.com/mc/cormas/Cormas/main which is not existing. Vincent -----Message d'origine----- De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Serge Stinckwich EnvoyÃ© : mardi 21 avril 2015 17:39 Ã : Any question about pharo is welcome Objet : Re: [Pharo-users] Wrong slave for CI job Thank you Vincent. I add the Slaves axis in the configuration and select 32, but the job is still running on raspberry pi ... On Tue, Apr 21, 2015 at 5:30 PM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > Hi, > > In the configuration of your job, you should add in the configuration matrix the slaves on which your job should be executed. > Click on add axis, and choose "Slaves" to add it. After you have to choose one label. I think that "32" is nice for a standard job. > > Best, > Vincent Blondeau > > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la > part de Serge Stinckwich EnvoyÃ© : mardi 21 avril 2015 17:17 Ã : Any > question about pharo is welcome Objet : [Pharo-users] Wrong slave for > CI job > > I add a new CI job > here:https://ci.inria.fr/pharo-contribution/job/Cormas/ > bu every time I try to run the job, the job is executed on a pharo-contribution-raspberrypi-linux slave and fails ... I try to change the node without success ... > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

April 21, 2015

Re: [Pharo-users] Wrong slave for CI job

by Serge Stinckwich

Thank you Vincent. I add the Slaves axis in the configuration and select 32, but the job is still running on raspberry pi ... On Tue, Apr 21, 2015 at 5:30 PM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > Hi, > > In the configuration of your job, you should add in the configuration matrix the slaves on which your job should be executed. > Click on add axis, and choose "Slaves" to add it. After you have to choose one label. I think that "32" is nice for a standard job. > > Best, > Vincent Blondeau > > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Serge Stinckwich > EnvoyÃ© : mardi 21 avril 2015 17:17 > Ã : Any question about pharo is welcome > Objet : [Pharo-users] Wrong slave for CI job > > I add a new CI job here:https://ci.inria.fr/pharo-contribution/job/Cormas/ > bu every time I try to run the job, the job is executed on a pharo-contribution-raspberrypi-linux slave and fails ... I try to change the node without success ... > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 21, 2015

Re: [Pharo-users] Wrong slave for CI job

by Blondeau Vincent

Hi, In the configuration of your job, you should add in the configuration matrix the slaves on which your job should be executed. Click on add axis, and choose "Slaves" to add it. After you have to choose one label. I think that "32" is nice for a standard job. Best, Vincent Blondeau -----Message d'origine----- De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Serge Stinckwich EnvoyÃ© : mardi 21 avril 2015 17:17 Ã : Any question about pharo is welcome Objet : [Pharo-users] Wrong slave for CI job I add a new CI job here:https://ci.inria.fr/pharo-contribution/job/Cormas/ bu every time I try to run the job, the job is executed on a pharo-contribution-raspberrypi-linux slave and fails ... I try to change the node without success ... -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

April 21, 2015

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

by Mariano Martinez Peck

Hi Stef, Similar to what Yanni said, 99% of our extensions are to Magritte-Seaside, not to magritte core itself. I honestly see Magritte as a very small and super extensible framework from which you can build your own on top of it. Like QCMagritte. Or likely what Yanni did, or likely what we did. That is...a set of subclasses/extensions to Magritte Seaside. This doesn't mean we shouldn't make this open-source, but I am just saying all our extensions should not be Magritte core code but kind of a framework build on top of Magritte core. Just to give you an idea of the extensibility of Magritte... is that with all our framework build on top of Magritte, we had NO OVERRIDE and our classes/extensions load cleanly after loading Magritte. Cheers, On Sat, Apr 18, 2015 at 4:55 PM, stepharo <stepharo(a)free.fr> wrote: > And BTW I would really like to see how we can do crude with > magritte-described objects. > > > Le 18/4/15 21:37, stepharo a Ã©crit : > > >> >> Le 18/4/15 20:04, Yanni Chiu a Ã©crit : >> >>> On Apr 18, 2015, at 2:18 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I found strange that not a single little improvements of Magritte was >>>> necessary for the Qude project. >>>> >>> Itâs not strange to me, because when working with Magritte 2, it seemed >>> that almost everything I wanted to do had a hook method to override, or an >>> obvious place to subclass or extend. So much so, that when I could not find >>> the extension point, I thought it was my fault. What was missing was >>> instance-based descriptions, which was added by the community in Magritte 3. >>> >> >> :) >> >> >>> Given how well-factored Magritte 2 was, my deduction was that a lot of >>> effort had already been done to extract out an open-source artefact, from >>> whatever system drove itâs development. So, no surprise that few >>> improvements to the core Magritte were needed. >>> >> >> Ok so we have perfect software. Good to know. >> >>> Now if heavy users of open-source libraries do not enhance these >>>> open-source libraries and keep their extensions >>>> under close source then the open-source libraries will never make >>>> progress and I will immensely sad. >>>> >>> Given that Magritte is already well-factored for extensions, what tends >>> to be written is exactly the custom code which you would not be releasing >>> to open-source. >>> >> >> but you see I did not use magritte since long time. It would be great to >> have example of custom-code. >> For example are relationships any useful. >> >>> >>> However, there might be a case for add-ons, such as Twitter Bootstrap >>> support. As mentioned in another post, changing the Magritte API/interfaces >>> at this point is tricky, because it would affect current users - thatâs the >>> conundrum: success and wider adoption will constrain the evolution. >>> >> We have versions to help there. >> >> The addition of instance-based descriptions was worth the (minor) pain >>> of the transition, but what level of pain would be tolerable to add >>> Bootstrap support, especially if youâre not using Bootstrap. >>> >> But we are talking about SeasideMagritte here? >> I do not know because I do not have experience. >> I was talking about magritte. >> >> >> >> >> > > -- Mariano http://marianopeck.wordpress.com

April 21, 2015