December 2018 - Pharo-users

Re: [Pharo-users] Teapot and SSL

by horrido

I've had tons of trouble trying to get Letsencrypt working. It was so frustrating that I decided to go with PositiveSSL from Comodo. It only cost me US$15.76 for two years, so I don't care about price. Letsencrypt's setup procedure is extremely arcane. For a noob like myself, this is not good. Moreover, it's a PITA to have to manually renew every three months. PositiveSSL removes all obstacles in one fell swoop. I'm using nginx as a reverse proxy. Again, as a total noob, I used the minimum, simplest configuration. I need help with one issue, though. Do I need to enable SSL in Pharo? After proxy pass, I only get HTTP. Here's my reverse-proxy.conf: *server { listen 80; location / { proxy_pass http://192.99.58.29:1701; } } server { listen 443; ssl_certificate /etc/nginx/cert_chain.crt; ssl_certificate_key /etc/nginx/cert.key; ssl on; location / { proxy_pass http://192.99.58.29:1701; } }* BTW, if you're curious about how my website looks, visit https://teams.jrmpc.ca It's still a work in progress. Things will undoubtedly change. Ben Coman wrote > On Sat, 22 Dec 2018 at 04:42, horrido < > horrido.hobbies@ > > wrote: >> >> Okay, I will dispense with the self-signed certificate and purchase a >> commercial one, say, from Comodo (PositiveSSL). > > My web host uses "Lets Encrypt" > https://www.dreamhost.com/hosting/ssl-tls-certificates/ > > I haven't looked into it deeply, but I've had no trouble with it. > > cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 22, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Gour

On Fri, 21 Dec 2018 17:02:48 -0500 Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Iceberg for code management (but supporting Fossil instead of Git). Fossil support in Iceberg is going to be officially supported? Sincerely, Gour -- A person who has given up all desires for sense gratification, who lives free from desires, who has given up all sense of proprietorship and is devoid of false ego â he alone can attain real peace.

Dec. 22, 2018

Re: [Pharo-users] Teapot and SSL

by Sven Van Caekenberghe

> On 22 Dec 2018, at 03:59, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > See my recent blog post: > > https://www.samadhiweb.com/blog/2018.12.09.https.html Wow, very well done, very well written, thank you.

Dec. 22, 2018

Re: [Pharo-users] GPS / Longitude / Latitude library

by Benoit St-Jean

Hi Alistair! First off, thanks for the "thank you note" in this email & on GitHub. Would you be interested in working on a port of GeoSphere (https://cran.r-project.org/web/packages/geosphere/geosphere.pdf) to Pharo ?Â I'll have some spare time in the next weeks so we could work on that together.Â Since this package is widely known and used, it could serve as a base for a Geo package for Pharo.Â I have R installed with this package here so cross-checking Pharo results vs R calculations wouldn't be a problem!Â That also means plenty of unit tests are possible !Â ;) I noticed (at least on Pharo 6.1) that you reference "WebBrowser" which is either present in P7 (and not in P6) or it indicates a dependency problem. I also noticed that you use the WGS84 reference ellipsoid as a hardcoded constant (in other works, assuming the earth radius is 6378137 meters for all calculations).Â Modifying the code to have reference ellipsoids objects and use the WGS84 as the default (which is what everyone uses) would be a more flexible solution. Besides, it would also allow funky stuff like being able to use the same framework to work for every known spatial body like say, the Moon or Mars or whatever! Besides, that way (using reference ellipsoid objects), older maps/coordinates/calculations could still be used just by changing the ellipsoid reference. Let me know if you're interested! P.S.Â I couldn't find a similar package/framework for Pharo/Squeak/WhateverSmalltalk.Â If I missed it, let me know guys!!Â I'm not a big fan of reinventing the wheel!! On 2018-12-19 02:32, Alistair Grant wrote: > Hi All, > > If anyone is interested, I've created the beginnings of a library for > handling coordinates at: https://github.com/akgrant43/GeoSphere > > It only: > > - Parses string coordinates > - Calculates the distance between coordinates > - Opens a web browser in OpenStreetMap at the receiver's coordinates > > Examples of string formats that can be parsed: > > - 144.61025 @ -38.28697 > - 38Â° 17â² 13.09â³ S, 144Â° 36â² 36.9â³ E > - 38 deg 17' 13.09" S, 144 deg 36' 36.9" E > - https://www.openstreetmap.org/#map=18/-38.28697/144.61025 > > The distance calculation uses haversine (assumes the earth is a > sphere), which is good enough for my needs at the moment. > > Thanks again to Sven, Benoit, Pierce and Richard for their input. > > Cheers, > Alistair > -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Dec. 22, 2018

Re: [Pharo-users] Teapot and SSL

by Pierce Ng

On Fri, Dec 21, 2018 at 02:42:04PM -0600, horrido wrote: > Okay, I will dispense with the self-signed certificate and purchase a > commercial one, say, from Comodo (PositiveSSL). Use Let's Encrypt-issued certificates, available without charge. Let's Encrypt's CA certificate is built-in trusted by all the major web browsers, meaning no action is required on the part of the web browser user when visiting a site over HTTPS with certificate issued by Let's Encrypt. Use Caddy as reverse proxy for your webapp. Caddy has transparent integration with Let's Encrypt: it generates/saves crypto keys, performs the Let's Encrypt protocol dances to request for and renew Let's Encrypt certificates, meaning no action is required on the part of the web site/app administrator after setting it up. Use Docker, which makes it easy to set up Caddy and your Pharo webapp. See my recent blog post: https://www.samadhiweb.com/blog/2018.12.09.https.html Pierce

Dec. 22, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Ben Coman

On Sat, 22 Dec 2018 at 06:03, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: > > First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. Was this on Windows? What was the fix for worked for you? (sorry its easier to ask again than try to identify in the archives a previous mention) cheers -ben > It was related with some mozilla library for font redering that didn't work well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. > > I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. > > This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. > > In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. > > Cheers, > > Offray > > On 21/12/18 10:59, Luke Gorrie wrote: > > On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. > > [...] >> >> Does this address the concern? > > > I am not sure yet :). > > Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. > > In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. > > The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. > > I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. > > Hints would be appreciated :) > > I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. > > Cheers! > -Luke > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi Offray, Thanks for describing your concerns. First, letâs address the technical part. Please go to gtoolkit.com and download the 64Bit distribution that includes the image and the VM. We will remove the standalone image option from the website until the VM situation gets clarified. Now, a clarification. The old GT was produced over a period of 4 years by an open-source team. The project had its own identity, and in 2014 the core of it was first integrated in Pharo. I say the core of it, because the visual part and other libraries are not in Pharo today. The full potential is found in Moose. In any case, during this process, GT got to be identified with Pharo and that was a good thing. The new GT is a product produced by feenk, a company. Much of the original team is still active in the new version, but now we commit to our product in a different way. The product is free and open-source, but itâs still a product with an identity and a goal. At present time, both the team, identity and goal are different than those of Pharo. Our goal is to offer a fundamentally new alternative to program (including comparing to what is possible now in Pharo). We are not looking for marginal improvements, and we are not aiming at backward compatibility. To build this alternative we invested in a whole new stack. That is not a tiny challenge and getting it right requires many iterations and feedback. We say we are in alpha not because of inconveniences of installation but because we are still very much developing the product. We announced the first alpha version in September and since then much has changed. At present time, we did manage to reach a situation where downloading the distribution should run on Mac, Linux and Windows. Even so, the current version is only for people that do want to try knowing that there will be hurdles. A word about the user experience. The current version runs inside the Pharo UI because we need to bootstrap. But, our goal is to build a complete IDE on the new stack. If you want to judge the user experience, it is only meaningful to do it within the GT windows, and not by comparing it with the rest of the existing Pharo UI. Does this clarify the situation? Cheers, Doru -- www.feenk.com "Every thing has its own flow." > On 21 Dec 2018, at 23:02, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: > > First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. It was related with some mozilla library for font redering that didn't work well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. > I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. > This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. > > In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. > > Cheers, > > Offray >> On 21/12/18 10:59, Luke Gorrie wrote: >> On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. >> [...] >>> Does this address the concern? >> >> I am not sure yet :). >> >> Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. >> >> In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. >> >> The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. >> >> I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. >> >> Hints would be appreciated :) >> >> I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. >> >> Cheers! >> -Luke >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-users] Teapot and SSL

by Ben Coman

On Sat, 22 Dec 2018 at 04:42, horrido <horrido.hobbies(a)gmail.com> wrote: > > Okay, I will dispense with the self-signed certificate and purchase a > commercial one, say, from Comodo (PositiveSSL). My web host uses "Lets Encrypt" https://www.dreamhost.com/hosting/ssl-tls-certificates/ I haven't looked into it deeply, but I've had no trouble with it. cheers -ben

Dec. 21, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Offray Vladimir Luna CÃ¡rdenas

Hi, I share your feeling of wonder and also concern Luke. In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: * First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. It was related with some mozilla library for font redering that didn't work well at the end. * Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. Cheers, Offray On 21/12/18 10:59, Luke Gorrie wrote: > On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > The goal of the new GT is to propose a completely reshaped > programming experience that enables moldable development. You will > find the concepts from the old GT in the new world as well. For > example, the Inspector is extensible in similar ways and the API > is similar as well. > > [...]Â > > Does this address the concern? > > > I am not sure yet :). > > Programming is not our main use case for GT. We are using GT as an > object inspector (etc) for examining diagnostic data. We have a > Smalltalk application that's similar to GDB and we are using GT as the > front-end. > > In our world we use the Inspector and the Spotter but all of the > Smalltalk programming views are hidden. GT is "molded" to be a > diagnostic tool *instead of* a programming environment. Specifically, > our main use case is inspecting/debugging the operation of a JIT > compiler written in C. We have Smalltalk code to load binary coredumps > from the JIT, decode them using DWARF debug information, and represent > the application-level compiler data structures as Smalltalk objects. > This way we can use GT to browse generated code, cross-reference > profiler data, examine runtime compilation errors, etc.Â > > The "old" GT is awesome for this. I feel like this application is also > very much in the spirit of the "moldable tools" thesis. Lots of > diagnostic workflows ultimately boil down to drill-down inspecting > and/or searching. > > I don't know where we stand with respect to the "new" GT though. I am > talking about diagnostics, you are talking about programming. I am > talking about zeros and ones, you are talking about feelings. I am > maintaining a stable application, you are talking about rewrites. I am > having a hard time whether I should be switching to the new GT in the > immediate future, or waiting another year or two for it to mature, or > planning to stick with the old GT. > > Hints would be appreciated :) > > I reiterate that I think you guys are doing fantastic work - some of > the most interesting work in the programming universe to my mind. I > hope that this discussion is useful for at least understanding the > thought process of some users / potential users. > > Cheers! > -Luke > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

And here is the tweet I was mentioning: https://twitter.com/feenkcom/status/1075011040373551104?s=21 Cheers, Doru -- www.feenk.com "Every thing has its own flow." > On 21 Dec 2018, at 21:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Thanks for detailing your thoughts. > > Indeed, I know about your application. Whatever you can do with the current GT you will be able to do with the new one. > > Except that for the new one you will be able to do extra things. Here are a few: > - You can build and share documents that embed those inspector views. This can be useful for reporting or sharing diagnostics with your users. > - Because the underlying rendering engine is much more powerful, you can express modern and interfaces that integrate with the rest of the environment smoothly. > - You likely have to deal with log files that might get large. First, the new editor allows you to smoothly work with such files. But, you can go well beyond this. Imagine that you build a tooling that produces the same editor only the text is interactive, and you might even embed visual artifacts right in the text to bridge the gap between what you would see in a typical console. For example, this tweet shows the new Transcript used to debug an animation. For every animation frame, we output the text corresponding with the frame and we insert the graphical preview corresponding to that step. > > You look at GT from the point of view of an end-user. You likely like the fact that you could mold the environment to your context and that you could do this incrementally. It happens that the same principles and tools can be applied to the whole programming, and once you do that, you actually can fundamentally change the act of programming. In fact, the same thing applies to the old GT: we built the new GT using that version and we believe that this allowed us to work much faster than if we would have used more traditional tools. The new GT pushes the envelope significantly further. > > So, that is why we are excited about that perspective, but even if you do not spend much time programming in Pharo, you can still take advantage for the user point of view as described above :). > > Is this answer better? > > Cheers, > Doru > > > >> On Dec 21, 2018, at 4:59 PM, Luke Gorrie <luke(a)snabb.co> wrote: >> >> On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. >> [...] >> Does this address the concern? >> >> I am not sure yet :). >> >> Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. >> >> In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. >> >> The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. >> >> I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. >> >> Hints would be appreciated :) >> >> I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. >> >> Cheers! >> -Luke >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Being happy is a matter of choice." > > > > >

Dec. 21, 2018