- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Guillermo Polito

We did a change last week on MCDataStream. We did it with the intention of making it backward compatible. Can somebody tell me a repo/package/version that I should try to load to reproduce it? Guille El miÃ©., 26 de ago. de 2015 a la(s) 12:00 p. m., Nicolai Hess < nicolaihess(a)web.de> escribiÃ³: > 2015-08-26 11:00 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> > On 26 Aug 2015, at 10:58, Blondeau Vincent < >> vincent.blondeau(a)worldline.com> wrote: >> > >> > Loading traits only is working, there are traits in Moose and it is >> well working... >> > E.g.: >> > Trait named: #TOODependencyQueries >> > uses: TDependencyQueries >> > category: 'Famix-Coreâ >> > >> >> Yes, but there it might not fall back on loading the .st file but instead >> de-seriaize the MC model. >> > > Yes, I think this is again > > MCMczReader>>loadDefinitions > definitions := OrderedCollection new. > (self zip memberNamed: 'snapshot.bin') ifNotNil: > [:m | [^ definitions := (MCDataStream on: m contentStream) next > definitions] > on: Error do: [:fallThrough]]. > "otherwise" > (self zip membersMatching: 'snapshot/*') > do: [:m | self extractDefinitionsFrom: m]. > > if the first run wit hMCDataStream on: ... fails, it uses the "otherwise" > path. > But that one does not handle Trait definitions correctly. > > I don't know why the first one (MCDataStream ...) fails on some packages, > may have something to do with > non-ascii characters but I don't know if it failed always at that place > and only the implementation in the > second path changed? > > > nicolai > > > > > > >> >> >> > Vincent >> > >> > -----Message d'origine----- >> > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la >> part de Marcus Denker >> > EnvoyÃ© : mercredi 26 aoÃ»t 2015 10:52 >> > Ã : Any question about pharo is welcome >> > Cc : Pharo Development List >> > Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview >> > >> > >> >> On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> >> >> Aha. Thanks for the help, Vincent. >> >> >> >> Now, the next problem: Does anyone know why the "Unrecognized class >> definition" problem occurs? :) >> >> >> > >> > It seems that >> > >> > 1) MC model loading of the serialised package fails >> > 2) it falls back on using MCStReader >> > 3) which fails to load the .st file for the definition of >> TBlLayoutPropertiesOwner >> > >> > Maybe loading trait definitions does not work in general with >> MCStReader? >> > >> > Marcus >> > >> > >> > 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. >> > >> >> >>

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Nicolai Hess

2015-08-26 11:00 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 26 Aug 2015, at 10:58, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > > > > Loading traits only is working, there are traits in Moose and it is well > working... > > E.g.: > > Trait named: #TOODependencyQueries > > uses: TDependencyQueries > > category: 'Famix-Coreâ > > > > Yes, but there it might not fall back on loading the .st file but instead > de-seriaize the MC model. > Yes, I think this is again MCMczReader>>loadDefinitions definitions := OrderedCollection new. (self zip memberNamed: 'snapshot.bin') ifNotNil: [:m | [^ definitions := (MCDataStream on: m contentStream) next definitions] on: Error do: [:fallThrough]]. "otherwise" (self zip membersMatching: 'snapshot/*') do: [:m | self extractDefinitionsFrom: m]. if the first run wit hMCDataStream on: ... fails, it uses the "otherwise" path. But that one does not handle Trait definitions correctly. I don't know why the first one (MCDataStream ...) fails on some packages, may have something to do with non-ascii characters but I don't know if it failed always at that place and only the implementation in the second path changed? nicolai > > > > Vincent > > > > -----Message d'origine----- > > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la > part de Marcus Denker > > EnvoyÃ© : mercredi 26 aoÃ»t 2015 10:52 > > Ã : Any question about pharo is welcome > > Cc : Pharo Development List > > Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > > > > > >> On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Aha. Thanks for the help, Vincent. > >> > >> Now, the next problem: Does anyone know why the "Unrecognized class > definition" problem occurs? :) > >> > > > > It seems that > > > > 1) MC model loading of the serialised package fails > > 2) it falls back on using MCStReader > > 3) which fails to load the .st file for the definition of > TBlLayoutPropertiesOwner > > > > Maybe loading trait definitions does not work in general with MCStReader? > > > > Marcus > > > > > > 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. > > > > >

Aug. 26, 2015

Re: [Pharo-dev] Working Directory and FileSystem

by Thierry Goubier

Hi Guile, http://forum.world.st/Working-directory-td4631865.html I think there is some discussions about that a while ago. Thierry 2015-08-26 11:32 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > (I cc the VM dev as this topic touches a bit the VM) > > Hi, chasing a bug I found that FileSystem does not handle well the working > directory of the system. The working directory of a process is the > directory from where we started the process. That is, the directory from > where we launched the VM with the image. > > However, FileSystem has two problems with this: > 1) it believes that the workingDirectory is where the image *is* and not > where it was open. (Check: FileSystem workingDirectory). > 2) if you try to use a relative file name FileSystem will use the working > directory he believes instead of letting the primitive do his job. (Just > open your image from another directory and do 'asd.txt' asFileReference > fullName). > > This problem becomes apparent when you use the launcher, or when you > launch your image from other directory. > > Now, I was checking with Santi how to obtain the working directory of the > process and we saw that there are two primitives """"included""" in the VM > as part of the OSProcess plugins to do it (Included as they are in the > PharoVM build). > > <primitive: 'primitiveGetCurrentWorkingDirectory' module: > 'Win32OSProcessPlugin' > > > AND > > <primitive: 'primitiveGetCurrentWorkingDirectory' module: > 'UnixOSProcessPlugin' > > > > So I'd like to propose: > - include those primitives in the default VM (as we already have the ones > to get the image file path and the vm file path). > - Add methods calling those primitives in OSPlatform and subclasses > - Change FileSystem to have the working directory work as expected. > > What do you think? > Guille >

Aug. 26, 2015

Working Directory and FileSystem

by Guillermo Polito

(I cc the VM dev as this topic touches a bit the VM) Hi, chasing a bug I found that FileSystem does not handle well the working directory of the system. The working directory of a process is the directory from where we started the process. That is, the directory from where we launched the VM with the image. However, FileSystem has two problems with this: 1) it believes that the workingDirectory is where the image *is* and not where it was open. (Check: FileSystem workingDirectory). 2) if you try to use a relative file name FileSystem will use the working directory he believes instead of letting the primitive do his job. (Just open your image from another directory and do 'asd.txt' asFileReference fullName). This problem becomes apparent when you use the launcher, or when you launch your image from other directory. Now, I was checking with Santi how to obtain the working directory of the process and we saw that there are two primitives """"included""" in the VM as part of the OSProcess plugins to do it (Included as they are in the PharoVM build). <primitive: 'primitiveGetCurrentWorkingDirectory' module: 'Win32OSProcessPlugin' > AND <primitive: 'primitiveGetCurrentWorkingDirectory' module: 'UnixOSProcessPlugin' > So I'd like to propose: - include those primitives in the default VM (as we already have the ones to get the image file path and the vm file path). - Add methods calling those primitives in OSPlatform and subclasses - Change FileSystem to have the working directory work as expected. What do you think? Guille

Aug. 26, 2015

Re: [Pharo-dev] Strange Validation with issue 15820

by Guillermo Polito

Ok, so we found the bug: The working directory of a process is the directory from where we started the process. That is, the directory from where we launched the VM with the image. Then, when we create a file without specifying a directory (that is, in a relative way), that file will be created in the working directory. However, FileSystem has two problems 1) it believes that the workingDirectory is where the image *is* and not where it was open. (Check FileSystem workingDirectory). 2) if you try to use a relative file name FileSystem will for you the working directory he believes instead of letting the primitive do his job. (Just open your image from another directory and do 'asd.txt' asFileReference fullName). So the fix to the test was: do not mix FileSystem with the low level File API. I'll open a new thread discussing about the working directory. Guille El mar., 25 de ago. de 2015 a la(s) 7:22 p. m., Ben Coman < btc(a)openinworld.com> escribiÃ³: > On Tue, Aug 25, 2015 at 11:30 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > > Hi, > > > > We have an issue that is platform dependent (file-related): > > > > https://pharo.fogbugz.com/f/cases/15820/Better-File-API > > > > Now, we tested with Nicolai in Windows, Mac and Linux and we had all > tests > > green. However, the monkey does not seem to want to be green. > > > > - Would anyone have an idea of what should be disturbing the monkey? > > No ideas, except if you can't isolate it, maybe its possible to SSH > into the CI server, map VNC ports back to your local machine and debug > the image on the CI server. > > cheers -ben > > > - Can people in different linuxes/unixes test the slice just to make > sure we > > are on the right path? (that is, load the slice and run the tests in the > > File package). > > > > Thanks a lot, > > Guille > >

Aug. 26, 2015

Re: [Pharo-dev] [ann] brick on top of bloc - preview

by stepharo

Excellent Two questions: Doru recently we (franck on a keyboard) played with the data source model of (mac) of FastTable. We are building a list with a search that displays only the matching element. This is interesting to see that we just have to provide a different (more elaborate datasource). We can show you a bit what we did. I was again rethinking how to compose/reuse logic (basically rethinking Spec ideas). The tension is that when we use composable models we by construction limit the functionality that can be composed. For example, it is difficult to expose all the behavior of rubric without explosing the API of Text. Now if we use directly widgets then how can we reuse the logic of the composition Alain started to brainstorm about it in calypso and I would like to discuss deeper this point. Stef I did not see email in the bloc mailing-list. Are you using it? I would be interested to see some discussions because I have a lot of little details that I came accross building "simple" UI and I would love to see how Brick handle them. > Hi, > > We are happy to announce the first preview version of Brick, a new > widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain > Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. > Brick is part of the Glamorous Toolkit effort and will provide the > basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the > default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various > visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the > mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place > editing) > > The next immediate target is the creation of a new Pager widget (the > widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Marcus Denker

> On 26 Aug 2015, at 10:58, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Loading traits only is working, there are traits in Moose and it is well working... > E.g.: > Trait named: #TOODependencyQueries > uses: TDependencyQueries > category: 'Famix-Coreâ > Yes, but there it might not fall back on loading the .st file but instead de-seriaize the MC model. > Vincent > > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Marcus Denker > EnvoyÃ© : mercredi 26 aoÃ»t 2015 10:52 > Ã : Any question about pharo is welcome > Cc : Pharo Development List > Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > > >> On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Aha. Thanks for the help, Vincent. >> >> Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) >> > > It seems that > > 1) MC model loading of the serialised package fails > 2) it falls back on using MCStReader > 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner > > Maybe loading trait definitions does not work in general with MCStReader? > > Marcus > > > 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. >

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Blondeau Vincent

Loading traits only is working, there are traits in Moose and it is well working... E.g.: Trait named: #TOODependencyQueries uses: TDependencyQueries category: 'Famix-Core' Vincent -----Message d'origine----- De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Marcus Denker EnvoyÃ© : mercredi 26 aoÃ»t 2015 10:52 Ã : Any question about pharo is welcome Cc : Pharo Development List Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Aha. Thanks for the help, Vincent. > > Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) > It seems that 1) MC model loading of the serialised package fails 2) it falls back on using MCStReader 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner Maybe loading trait definitions does not work in general with MCStReader? Marcus 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.

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Marcus Denker

> On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Aha. Thanks for the help, Vincent. > > Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) > It seems that 1) MC model loading of the serialised package fails 2) it falls back on using MCStReader 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner Maybe loading trait definitions does not work in general with MCStReader? Marcus

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Tudor Girba

Aha. Thanks for the help, Vincent. Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) Cheers, Doru On Wed, Aug 26, 2015 at 9:14 AM, Vincent BLONDEAU < vincent.blondeau(a)polytech-lille.net> wrote: > Now that the Moose 6.0 job is working, the last build of Pharo is used and > the problem appears in the CI... > > Vincent > > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part > de Alexandre Bergel > EnvoyÃ© : mercredi 26 aoÃ»t 2015 01:02 > Ã : Any question about pharo is welcome > Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > > Wowâ¦ > > Alexandre > > > > On Aug 25, 2015, at 6:41 PM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > > > That is because GToolkit is based on last successful Moose 6.0 build > where everything works fine (it is Pharo50248). > > But less than a week ago, a featured bug was integrated in Pharo and it > is not possible to load Moose anymoreâ¦ That is due to some encoding > problems during Monticello loading between 50256 and 50257 Pharo versions > (integration of Slice 16283). > > > > As I canât load brick on the 50256 pharo image, I think that the bug you > encounter has been introduced before, i.e. between 50248 and 50256. So it > is not related to the Moose one. > > Bernardoâs bug is related to traits loading, I have the same bug for one > of my project but I didnât investigate it yet. > > > > Cheers, > > Vincent > > > > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la > > part de Tudor Girba EnvoyÃ© : mardi 25 aoÃ»t 2015 23:08 Ã : Any question > > about pharo is welcome Objet : Re: [Pharo-users] [ann] brick on top of > > bloc - preview > > > > Hmm. Thanks for the report. Indeed, I get the same, but the CI job works > well. We will have to investigate this. > > > > In the meantime, you can use the image from: > > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/g > > toolkit5.zip > > > > Cheers, > > Doru > > > > > > > > On Tue, Aug 25, 2015 at 10:51 PM, Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com> wrote: > >> i forgot to mention that it was while > >> > >> Loading Bloc-Core-AliakseiSyrel.636 > >> > >> thanks > >> > >> > >> > >> On Tue, Aug 25, 2015 at 5:43 PM, Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com> wrote: > >>> Sorry, but after evaluating > >>> > >>> Gofer new > >>> smalltalkhubUser: 'Pharo' project: 'Brick'; configuration; > >>> loadDevelopment > >>> > >>> in Pharo5.0#50270, i got an Error: Unrecognized class definition > >>> > >>> The screenshots look really cool. > >>> > >>> thanks > >>> > >>> > >>> On Tue, Aug 25, 2015 at 5:13 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>>> Hi, > >>>> > >>>> We are happy to announce the first preview version of Brick, a new > widget set created from scratch on top of Bloc. > >>>> > >>>> Brick is being developed primarily by Alex Syrel (together with Alain > Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick > is part of the Glamorous Toolkit effort and will provide the basis for the > new versions of the development tools. > >>>> > >>>> Brick's goal is to provide a beautiful looking widget set, and the > default look is based on material design. The widgets are theme-able. > >>>> > >>>> Right now, there exists: > >>>> - Label > >>>> - Simple button > >>>> - Toggle button > >>>> - Checkbox > >>>> - Radio button > >>>> - Window with or without an active title bar that can include > >>>> various visual actions and info > >>>> - Menu > >>>> - Beautiful scrollbars that are thin by default and enlarge when > >>>> the mouse hovers over it > >>>> - Scalable list for huge amounts of items with various heights (The > >>>> list also allows one for embedding text widgets with in place > >>>> editing) > >>>> > >>>> The next immediate target is the creation of a new Pager widget (the > widget that is behind the current GTInspector). > >>>> > >>>> You can see some screenshots on the official site: > >>>> http://gt.moosetechnology.org/brick > >>>> > >>>> To play with it, you can download a ready-made image: > >>>> https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifac > >>>> t/gtoolkit5.zip > >>>> > >>>> and, in a Bloc space, you can browse the examples: > >>>> BrExampleBrowser exampleOpen > >>>> > >>>> We would be happy to hear your feedback. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every thing has its own flow" > >>> > >>> > >>> > >>> -- > >>> Bernardo E.C. > >>> > >>> Sent from a cheap desktop computer in South America. > >> > >> > >> > >> -- > >> Bernardo E.C. > >> > >> Sent from a cheap desktop computer in South America. > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 26, 2015