October 2020 - Pharo-users - lists.pharo.org

Re: Constraint solver in Pharo?

by Alexandre Bergel

Thanks! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On 28-10-2020, at 04:22, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Long time ago Guillaume Grondin ported BackTalk the constraints library by Pierre Roy and FranÃ§ois Pachet from LIP6 to Squeak. http://www.squeaksource.com/@VoaaA0m8tASxYTuS/QN-qUhcD <http://www.squeaksource.com/@VoaaA0m8tASxYTuS/QN-qUhcD> > On Oct 27 2020, at 2:52 pm, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hello! > > Is there a constraint solver available in Pharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 29, 2020

Re: Constraint solver in Pharo?

by Noury Bouraqadi

Long time ago Guillaume Grondin ported BackTalk the constraints library by Pierre Roy and FranÃ§ois Pachet from LIP6 to Squeak. http://www.squeaksource.com/@VoaaA0m8tASxYTuS/QN-qUhcD On Oct 27 2020, at 2:52 pm, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hello! > > Is there a constraint solver available in Pharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >

Oct. 28, 2020

Re: Constraint solver in Pharo?

by StÃ©phane Ducasse

There is cassowary and deltablue. S. > On 27 Oct 2020, at 14:52, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hello! > > Is there a constraint solver available in Pharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 27, 2020

Constraint solver in Pharo?

by Alexandre Bergel

Hello! Is there a constraint solver available in Pharo? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 27, 2020

[ANN] Next Pharo Sprint: Oct 30

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Oct 30 (this Friday) Goals of this sprint: - Fix issues from tracker https://github.com/pharo-project/pharo/issues This is a Remote Sprint, it happens on Discord. http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 A list of all Pharo Event of the year an be found here: https://association.pharo.org/events

Oct. 27, 2020

GSOC 2021

by Serge Stinckwich

GSOC 2021 is out: https://summerofcode.withgoogle.com/ Anyone is willing to lead the Pharo proposal? Regards, -- Serge Stinckwic h https://twitter.com/SergeStinckwich

Oct. 27, 2020

[Ann] IndieWeb and pocket infrastructures: 6th biweekly workshop this Saturday (3:15 PM - 7:15 PM, GMT-5)

by Offray Vladimir Luna CÃ¡rdenas

Hi all, This is just a short reminder about our biweekly Grafoscopio community workshops about IndieWeb and pocket infrastructures (in Spanish). You can find more information about them on: [1] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html#tall… It has been really nice to see how workshops, prose and code advance intertwined and feedback each other in this community experience made on a voluntary basis. In the "behind scenes" links below you can see how the writing advances at a pretty good pace. By a happy coincidence, that I think is more a reflection of the spirit of our times, we, at the local community, started to develop a so called decoupled/headless CMS, that suits our writing and publishing workflows better that overcomplicated CMS (like WordPress) and after that I found that there is a complete movement around them, that includes static generators[1] and JAMStack. Our approach aligns with them in some places and in others I think we are more agile and minimalist. As usual, I create an interactive Grafoscopio outline/notebook and a Domain Specific Language that explores the problem and creates some prototypes (see screenshot below). We have biweekly community workshops[2a], where we learn how to build, update and modify our static site and the technologies behind and the companion documentation site[2] is an exampler and explainer of what can be done using the Brea[3] minimalist CMS under construction: [1] https://jamstack.org/generators/ [2] https://mutabit.com/repos.fossil/indieweb/ [2a] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html#tall… [3] https://mutabit.com/repos.fossil/brea/ As usual, I would like to thanks the remote community that makes this local experience possible, and also I would like to thank ESUG for their key support to this initiative. Cheers, Offray Ps: here are the "behind scenes" links * https://mutabit.com/repos.fossil/indieweb/timeline * https://mutabit.com/repos.fossil/indieweb/tree?ci=tip&name=docs/es&type=tree * https://code.tupale.co/Offray/Brea * https://mutabit.com/repos.fossil/brea/

Oct. 23, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by stephan

For some situations, creating something on github might be a perfectly good persistence strategy. Stephan

Oct. 22, 2020

Pharo Mars still not working on Ubuntu

by kmo

I see that the Pharo-Mars code has recently been split into two projects. Unfortunately this has still not fixed the problem with Ubuntu. It is still totally impossible to run pharo mars on ubuntu. Now just loading the GTK-bindings package into ubuntu causes a segfault. This is actually going backwards - at least you used to be able to load the code into pharo, even though it crashed if you tried to use it. i flagged this up in May. I'm beginning to think I'll be dead before I see Ubuntu running Pharo-Mars. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 22, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Richard O'Keefe

The energy comparison web site is a useful reference. However, it measures a combination of - hardware platform - operating system (for example, FASTA does oodles of output) - compiler - runtime system (for example, garbage collector) - algorithm. Where there are multiple algorithms for a single language, we can see that that matters a LOT. For example, the fastest Rust code for FASTA is five times faster than the slowest, and we can expect a similar range in energy use. In the case of Smalltalk, do we expect Pharo and Amber to have the same time or energy costs? One of my earliest papers examined a "language X vs language Y" paper where I pointed out that they had compared moderately bad language X code to appallingly bad language Y code and when you improved both the only real difference was the efficiency of the 'print' function in each language. For this reason, amongst others, if you want to compare *languages*, you need multiple implementations in each language, otherwise what you are measuring is as much programmer skill as anything else. The one supremely useful thing in the language efficiency paper is that all the code they used is on github, including the tool they used to measure energy use. (It's a software-only tool.) That means that you can do your own measurements, and that's what really matters. On Wed, 21 Oct 2020 at 03:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Here is an interesting article that could help as a start: > > > https://thenewstack.io/which-programming-languages-use-the-least-electricit… > > Cheers, > > > On Thu, Oct 15, 2020 at 8:41 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > >> It doesn't make a whole lot of sense to talk about the energy efficiency >> of a programming language. For example, I've seen the run time of a >> C benchmark go from 50 seconds to 1 microsecond when the optimisation >> level was changed. It doesn't even make much sense to talk about the >> energy efficiency of the code generated by a specific compiler with >> specific options: the underlying hardware counts too. A colleague of >> mine, looking at text compression algorithms for an information retrieval >> engine, found that the fastest algorithm depended on just which x86-64 >> chip, even what motherboard, was in use. It's obviously going to be >> the same for energy efficiency. >> >> So let's specify a particular physical machine, a particular compiler, >> and a particular set of compiler options. NOW does it make sense to >> talk about energy efficiency? Nope. It's going to depend on the >> problem as well. And the thing is that people tend to do different >> things in different programming languages, and different communities >> attract different support. There is no portable Smalltalk equivalent >> of NumPy, able to automatically take advantage of GPUs, for example. >> >> You can get some real surprises. >> For example, just now while writing this message, I fired up >> powerstat(8). I had the browser open and power consumption was >> about 12.8 W. I then launched Squeak and ran some benchmarks. >> Power consumption went DOWN to 11.4 W. >> That is, Squeak was "costing" me -1.4 W. >> >> If you understand the kind of things modern CPUs get up to, that >> is not as surprising as it seems. All it demonstrates is that >> getting MEANINGFUL answers is hard enough; getting GENERALISBLE >> answers is going to be, well, if anyone succeeded, I think they >> would have earned at least a Masters. >> >> >> On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren < >> jvalteren(a)objectguild.com> wrote: >> >>> Hi StÃ©phane, >>> >>> Thanks for your feedback. I agree that the usefulness of these results >>> is limited. However, if we (Object Guild) want to make a case for energy >>> efficiency, it can help if the language itself can be shown to be efficient >>> as well. >>> >>> For now, I think the efficiency will need to come from a good object >>> design. >>> >>> Kind regards, >>> >>> Jonathan van Alteren >>> >>> Founding Member | Object Guild B.V. >>> *Sustainable Software for Purpose-Driven Organizations* >>> >>> On 11 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, >>> wrote: >>> >>> The problem is that what do you measure. >>> When you move computation from the CPU to a GPU for example does it >>> consume less or more. >>> I think that such analyses are totally stupid. >>> Is a fast execution consume less? I have serious doubts about it. >>> Now if we measure how fast we drain a battery because of polling vs >>> event based then this is different. >>> >>> S. >>> >>> On 1 Oct 2020, at 13:47, Jonathan van Alteren <jvalteren(a)objectguild.com> >>> wrote: >>> >>> Hi all, >>> >>> I am interested in energy efficiency metrics for Pharo (version >=8). >>> Just now, I came across this research and related GitHub project: >>> >>> - https://sites.google.com/view/energy-efficiency-languages >>> - https://github.com/greensoftwarelab/Energy-Languages >>> >>> >>> Unfortunately, the paper mentions that Smalltalk was excluded from the >>> results because the (VW) compiler was proprietary :-S However, the GitHub >>> repository does contain Smalltalk code and results, but I haven't been able >>> to evaluate those. >>> >>> [1] Does anyone here have more information on this topic? >>> >>> >>> The benchmarks seem to be low-level algorithms. Although that is useful, >>> I think that a better argument for Pharo/Smalltalk efficiency is that a >>> good OO design (e.g. created using responsibility-driven design with >>> behaviorally complete objects) will be a better fit, can be much simpler >>> and will thus be more efficient during development, as well as easier to >>> maintain and evolve. >>> >>> [2] Has anyone done any research in this area that can quantify this >>> aspect? >>> >>> Kind regards, >>> >>> Jonathan van Alteren >>> >>> Founding Member | Object Guild B.V. >>> *Sustainable Software for Purpose-Driven Organizations* >>> >>> jvalteren(a)objectguild.com >>> >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr / http://www.pharo.org >>> 03 59 35 87 52 >>> Assistant: Aurore Dalle >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >>> > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com > Twitter: @MartinezPeck > LinkedIn: www.linkedin.com/in/mariano-martinez-peck > <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> > Blog: https://marianopeck.wordpress.com/ >

Oct. 21, 2020

Re: Zinc question (may be this is an HTML one)

by StÃ©phane Ducasse

> > This is an HTTP question (the protocol, not HTML the document format). Yes this is what I meant but the mail was sent. > And you solved your problem well, I never tried it like that myself ;-) > > I would not write it differently. > > Like the comment says, it will only work with those types recognised by ImageReadWriter, which are the most common ones, JPG, GIF and PNG. > > Image/* is a wildcard matching any image type, and there are many, many more. > > The current mechanism in Zinc with #accept: and #enforceAcceptContentType: true assumes a singular 'Accept' header. But indeed, technically, it is possible to specify more than one. > > For example, this also works: > > ZnClient new > url: 'http://pharo.org/files/pharo.png <http://pharo.org/files/pharo.png>'; > headerAt: 'Accept' add: ZnMimeType imageGif asString; > headerAt: 'Accept' add: ZnMimeType imagePng asString; > headerAt: 'Accept' add: ZnMimeType imageJpeg asString; > contentReader: [ :entity | ImageReadWriter formFromStream: entity readStream ]; > get. Ah this would be better for me because like that I can probably control which exception is raised. Because we do not support image/svg > But I have to think a bit about this issue. > > Another approach is to use the extension of the URL. > > ZnMimeType forFilenameExtension: 'http://pharo.org/files/pharo.png <http://pharo.org/files/pharo.png>' asUrl file asFileReference extension. > > It all depends at what level you want to tell your user they tried getting an unsupported file type. Broad :) but soon you will be my user and you will have the right to complain :) > > Sven > >> S. >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 20, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Mariano Martinez Peck

Here is an interesting article that could help as a start: https://thenewstack.io/which-programming-languages-use-the-least-electricit… Cheers, On Thu, Oct 15, 2020 at 8:41 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > It doesn't make a whole lot of sense to talk about the energy efficiency > of a programming language. For example, I've seen the run time of a > C benchmark go from 50 seconds to 1 microsecond when the optimisation > level was changed. It doesn't even make much sense to talk about the > energy efficiency of the code generated by a specific compiler with > specific options: the underlying hardware counts too. A colleague of > mine, looking at text compression algorithms for an information retrieval > engine, found that the fastest algorithm depended on just which x86-64 > chip, even what motherboard, was in use. It's obviously going to be > the same for energy efficiency. > > So let's specify a particular physical machine, a particular compiler, > and a particular set of compiler options. NOW does it make sense to > talk about energy efficiency? Nope. It's going to depend on the > problem as well. And the thing is that people tend to do different > things in different programming languages, and different communities > attract different support. There is no portable Smalltalk equivalent > of NumPy, able to automatically take advantage of GPUs, for example. > > You can get some real surprises. > For example, just now while writing this message, I fired up > powerstat(8). I had the browser open and power consumption was > about 12.8 W. I then launched Squeak and ran some benchmarks. > Power consumption went DOWN to 11.4 W. > That is, Squeak was "costing" me -1.4 W. > > If you understand the kind of things modern CPUs get up to, that > is not as surprising as it seems. All it demonstrates is that > getting MEANINGFUL answers is hard enough; getting GENERALISBLE > answers is going to be, well, if anyone succeeded, I think they > would have earned at least a Masters. > > > On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren < > jvalteren(a)objectguild.com> wrote: > >> Hi StÃ©phane, >> >> Thanks for your feedback. I agree that the usefulness of these results is >> limited. However, if we (Object Guild) want to make a case for energy >> efficiency, it can help if the language itself can be shown to be efficient >> as well. >> >> For now, I think the efficiency will need to come from a good object >> design. >> >> Kind regards, >> >> Jonathan van Alteren >> >> Founding Member | Object Guild B.V. >> *Sustainable Software for Purpose-Driven Organizations* >> >> On 11 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, >> wrote: >> >> The problem is that what do you measure. >> When you move computation from the CPU to a GPU for example does it >> consume less or more. >> I think that such analyses are totally stupid. >> Is a fast execution consume less? I have serious doubts about it. >> Now if we measure how fast we drain a battery because of polling vs event >> based then this is different. >> >> S. >> >> On 1 Oct 2020, at 13:47, Jonathan van Alteren <jvalteren(a)objectguild.com> >> wrote: >> >> Hi all, >> >> I am interested in energy efficiency metrics for Pharo (version >=8). >> Just now, I came across this research and related GitHub project: >> >> - https://sites.google.com/view/energy-efficiency-languages >> - https://github.com/greensoftwarelab/Energy-Languages >> >> >> Unfortunately, the paper mentions that Smalltalk was excluded from the >> results because the (VW) compiler was proprietary :-S However, the GitHub >> repository does contain Smalltalk code and results, but I haven't been able >> to evaluate those. >> >> [1] Does anyone here have more information on this topic? >> >> >> The benchmarks seem to be low-level algorithms. Although that is useful, >> I think that a better argument for Pharo/Smalltalk efficiency is that a >> good OO design (e.g. created using responsibility-driven design with >> behaviorally complete objects) will be a better fit, can be much simpler >> and will thus be more efficient during development, as well as easier to >> maintain and evolve. >> >> [2] Has anyone done any research in this area that can quantify this >> aspect? >> >> Kind regards, >> >> Jonathan van Alteren >> >> Founding Member | Object Guild B.V. >> *Sustainable Software for Purpose-Driven Organizations* >> >> jvalteren(a)objectguild.com >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

Oct. 20, 2020

Re: Zinc question (may be this is an HTML one)

by Sven Van Caekenberghe

Hi Stef, > On 20 Oct 2020, at 09:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi sven and others > > > While trying to improve microdown I have the following question. > How can I have a more generic getImage: method. > > Right now I use getPng: and I would like to support getPng: and getJpeg. > > I saw that there is getImageOfType: mimeType fromUrl: urlObject > > > getImageOfType: mimeType fromUrl: urlObject > | client | > (client := self client) > url: urlObject; > accept: mimeType; > enforceHttpSuccess: true; > enforceAcceptContentType: true; > get. > "ImageReadWriter does automatic type detection" > ^ ImageReadWriter formFromStream: client entity readStream > > So it looks like what I want except that I do not know how to specify a Mime > > So I did > > ZnEasy > getImageOfType: (ZnMimeType main: 'image' sub: '*') > fromUrl: 'http://pharo.org/files/pharo.png' > > Now I would like to know if this is the correct way to do it. > I could imagine that we could give a set of possible mime types. This is an HTTP question (the protocol, not HTML the document format). And you solved your problem well, I never tried it like that myself ;-) I would not write it differently. Like the comment says, it will only work with those types recognised by ImageReadWriter, which are the most common ones, JPG, GIF and PNG. Image/* is a wildcard matching any image type, and there are many, many more. The current mechanism in Zinc with #accept: and #enforceAcceptContentType: true assumes a singular 'Accept' header. But indeed, technically, it is possible to specify more than one. For example, this also works: ZnClient new url: 'http://pharo.org/files/pharo.png'; headerAt: 'Accept' add: ZnMimeType imageGif asString; headerAt: 'Accept' add: ZnMimeType imagePng asString; headerAt: 'Accept' add: ZnMimeType imageJpeg asString; contentReader: [ :entity | ImageReadWriter formFromStream: entity readStream ]; get. But I have to think a bit about this issue. Another approach is to use the extension of the URL. ZnMimeType forFilenameExtension: 'http://pharo.org/files/pharo.png' asUrl file asFileReference extension. It all depends at what level you want to tell your user they tried getting an unsupported file type. Sven > S. > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Oct. 20, 2020

Zinc question (may be this is an HTML one)

by StÃ©phane Ducasse

Hi sven and others While trying to improve microdown I have the following question. How can I have a more generic getImage: method. Right now I use getPng: and I would like to support getPng: and getJpeg. I saw that there is getImageOfType: mimeType fromUrl: urlObject getImageOfType: mimeType fromUrl: urlObject | client | (client := self client) url: urlObject; accept: mimeType; enforceHttpSuccess: true; enforceAcceptContentType: true; get. "ImageReadWriter does automatic type detection" ^ ImageReadWriter formFromStream: client entity readStream So it looks like what I want except that I do not know how to specify a Mime So I did ZnEasy getImageOfType: (ZnMimeType main: 'image' sub: '*') fromUrl: 'http://pharo.org/files/pharo.png' Now I would like to know if this is the correct way to do it. I could imagine that we could give a set of possible mime types. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 20, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Richard O'Keefe

It doesn't make a whole lot of sense to talk about the energy efficiency of a programming language. For example, I've seen the run time of a C benchmark go from 50 seconds to 1 microsecond when the optimisation level was changed. It doesn't even make much sense to talk about the energy efficiency of the code generated by a specific compiler with specific options: the underlying hardware counts too. A colleague of mine, looking at text compression algorithms for an information retrieval engine, found that the fastest algorithm depended on just which x86-64 chip, even what motherboard, was in use. It's obviously going to be the same for energy efficiency. So let's specify a particular physical machine, a particular compiler, and a particular set of compiler options. NOW does it make sense to talk about energy efficiency? Nope. It's going to depend on the problem as well. And the thing is that people tend to do different things in different programming languages, and different communities attract different support. There is no portable Smalltalk equivalent of NumPy, able to automatically take advantage of GPUs, for example. You can get some real surprises. For example, just now while writing this message, I fired up powerstat(8). I had the browser open and power consumption was about 12.8 W. I then launched Squeak and ran some benchmarks. Power consumption went DOWN to 11.4 W. That is, Squeak was "costing" me -1.4 W. If you understand the kind of things modern CPUs get up to, that is not as surprising as it seems. All it demonstrates is that getting MEANINGFUL answers is hard enough; getting GENERALISBLE answers is going to be, well, if anyone succeeded, I think they would have earned at least a Masters. On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren < jvalteren(a)objectguild.com> wrote: > Hi StÃ©phane, > > Thanks for your feedback. I agree that the usefulness of these results is > limited. However, if we (Object Guild) want to make a case for energy > efficiency, it can help if the language itself can be shown to be efficient > as well. > > For now, I think the efficiency will need to come from a good object > design. > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > *Sustainable Software for Purpose-Driven Organizations* > > On 11 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, > wrote: > > The problem is that what do you measure. > When you move computation from the CPU to a GPU for example does it > consume less or more. > I think that such analyses are totally stupid. > Is a fast execution consume less? I have serious doubts about it. > Now if we measure how fast we drain a battery because of polling vs event > based then this is different. > > S. > > On 1 Oct 2020, at 13:47, Jonathan van Alteren <jvalteren(a)objectguild.com> > wrote: > > Hi all, > > I am interested in energy efficiency metrics for Pharo (version >=8). Just > now, I came across this research and related GitHub project: > > - https://sites.google.com/view/energy-efficiency-languages > - https://github.com/greensoftwarelab/Energy-Languages > > > Unfortunately, the paper mentions that Smalltalk was excluded from the > results because the (VW) compiler was proprietary :-S However, the GitHub > repository does contain Smalltalk code and results, but I haven't been able > to evaluate those. > > [1] Does anyone here have more information on this topic? > > > The benchmarks seem to be low-level algorithms. Although that is useful, I > think that a better argument for Pharo/Smalltalk efficiency is that a good > OO design (e.g. created using responsibility-driven design with > behaviorally complete objects) will be a better fit, can be much simpler > and will thus be more efficient during development, as well as easier to > maintain and evolve. > > [2] Has anyone done any research in this area that can quantify this > aspect? > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > *Sustainable Software for Purpose-Driven Organizations* > > jvalteren(a)objectguild.com > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

Oct. 15, 2020

Re: Why does loading baselines in P8 gives multiple entries in Iceberg?

by Gabriel Cotelli

It's already reported: https://github.com/pharo-project/pharo/issues/5881 On Thu, Oct 15, 2020 at 6:16 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi guys - having not worked on a proper project in Pharo for a while, I > was a bit surprised in Pharo 8 to see that when I load a project baseline, > it seems to appear multiple times in Iceberg? Is this a known issue - or am > I forgetting to do something? > > I noticed this for CodeParadise, but also have noticed it for my latest > project tooâ¦ it seems benign, the second one appears as a detached copy > when I commit changes on one of the entries - but its not something that I > recall seeing in earlier Pharo versions (like P7). > > Tim > >

Oct. 15, 2020

Why does loading baselines in P8 gives multiple entries in Iceberg?

by Tim Mackinnon

Hi guys - having not worked on a proper project in Pharo for a while, I was a bit surprised in Pharo 8 to see that when I load a project baseline, it seems to appear multiple times in Iceberg? Is this a known issue - or am I forgetting to do something? I noticed this for CodeParadise, but also have noticed it for my latest project tooâ¦ it seems benign, the second one appears as a detached copy when I commit changes on one of the entries - but its not something that I recall seeing in earlier Pharo versions (like P7). Tim

Oct. 15, 2020

Re: AthensCairoSDLSurface P8 Error

by Alvaro Piorno

HI StÃ©phane, It works fine in P9 changing for the new implementors of handle. Thanks El dom., 11 oct. 2020 a las 11:57, StÃ©phane Ducasse (< stephane.ducasse(a)inria.fr>) escribiÃ³: > Hello alvaro > > can you try with P9 because we got many improvements. > > S > > On 18 Sep 2020, at 22:07, Alvaro Piorno <alvaropiorno100(a)gmail.com> wrote: > > Hello, > > This code that worked for P6 and P7 is now failing in P8. > > *AthensCairoSDLSurface fromSDLSurface: self window handle handle > getWindowSurface.* > > the window is created like this: > > *window := OSWindow createWithAttributes: (OSWindowAttributes new > resizable: false; yourself).* > > The exception is Error: Could not coerce arguments > > from cairo lib. > > > Cheers > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

Oct. 14, 2020

UK Smalltalk User Group Meeting - Wednesday, October 28th

by Giovanni Corriga

The next meeting of the UK Smalltalk User Group will be on Wednesday, October 28th. Alexandre Bergel will talk about Agile Visualization with Roassal3. Visualizing data is probably the easiest part in the field of data visualization. Numerous books and sophisticated libraries exist for that very purpose. One of challenges of data visualization is to identify the right abstractions that make a visualization reusable, composable, extensible, navigable, and produced at a very low cost. Roassal ( https://github.com/ObjectProfile/Roassal3 ) is a visualization engine for Smalltalk that leverage the experience of crafting and using data visualization. This talk will demo Roassal and presents non-trivial visualizations within the field of software visualization. Alexandre Bergel ( http://bergel.eu/ ) is Associate Professor and researcher at the University of Chile. Alexandre Bergel and his collaborators carry out research in software engineering. His focus is on designing tools and methodologies to improve the overall performance and internal quality of software systems, by employing profiling, visualization, and artificial intelligence techniques. Alexandre Bergel has authored over 140 articles, published in international and peer reviewed scientific forums, including the most competitive conferences and journals in the field of software engineering. Alexandre has participated to over 140 program committees of international events. Alexandre has also a strong interest in applying his research results to industry. Several of his research prototypes have been turned into products and adopted by major companies in the semi-conductor industry and certification of critical software systems. Alexandre is member of the editorial board of Empirical Software Engineering. Alexandre authored the book Agile Artificial Intelligence in Pharo, Agile Visualization ( http://agilevisualization.com/ ), and co-authored the book Deep Into Pharo. Given the current COVID-19 restrictions, this will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/UKSTUG/events/cbklbrybcnblc/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

Oct. 14, 2020

Re: Energy efficiency of Pharo/Smalltalk

by StÃ©phane Ducasse

> On 13 Oct 2020, at 21:33, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > Hi StÃ©phane, > > I dug around a little bit regarding this subject and found that people are working to create software that is aware of its energy consumption. There is a Dutch university research group actively involved with this and related topics here: http://s2group.cs.vu.nl/mission/ <http://s2group.cs.vu.nl/mission/>. Well if you accept that your web browser is going slower may be you will consume less energy. Or may be your speedy web browser consumes less. > This article might be a good read on the subject: https://research.vu.nl/en/publications/a-manifesto-for-energy-aware-software <https://research.vu.nl/en/publications/a-manifesto-for-energy-aware-software> I skimmed over it and it is wishful thinking. How can I engineer a system (besides using good algorithms instead of sloppy one) to consume less energy, if we do not know what means energy aware: At then this is what? - Number of instructions executed, the least the better? - What about missed caches? - What about missed instruction pipelining? For example on your mac when you unplug the cable you have a different card setup because the videos card can consume more. So we can degrade certain operation. But how to measure this seriously. > > Is this something that could be of interest to Inria or the Pharo project? It depends how money is put on the table. :) > What do you mean exactly with your last comment? I think that when distinctions in a domain are successfully made explicit at design time, this will improve performance at runtime and thus should also improve energy efficiency. How does that relate to your comment about message passing/branching/polymorphism? To me Iâm sorry but I do not buy without serious measurement that " distinctions in a domain are successfully made explicit at design time, this will improve performance at runtime â Let us play the scientific here for a moment: do you have data? did you measure it? what are you biais in your measurement/experiment. Now to reply to your question in OORP we promote that case statement were bad that we it is better to use message passing. Except that in some domains in some specific circumstances have case statement is faster. Similarly they are domains where GC is a problem. > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > Sustainable Software for Purpose-Driven Organizations > > jvalteren(a)objectguild.com > On 13 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, wrote: >> >>> Hi StÃ©phane, >>> >>> Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. >> >> I do not know what is energy efficient nor how it is measurable. >> Now our objectives is that pharo does not burn the batteries when doing nothing and we start to have that with the headless and idle vm. >> >>> For now, I think the efficiency will need to come from a good object design. >> >> this would presume that message passing is faster than branching. >> And I remember that we had argument with hardware people about our reengineering pattern >> on condition to polymorphism >> >> >>> >>> Kind regards, >>> >>> Jonathan van Alteren >>> >>> Founding Member | Object Guild B.V. >>> Sustainable Software for Purpose-Driven Organizations >>> >>> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 13, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Jonathan van Alteren

Hi StÃ©phane, I dug around a little bit regarding this subject and found that people are working to create software that is aware of its energy consumption. There is a Dutch university research group actively involved with this and related topics here:Â http://s2group.cs.vu.nl/mission/. This article might be a good read on the subject:Â https://research.vu.nl/en/publications/a-manifesto-for-energy-aware-software Is this something that could be of interest to Inria or the Pharo project? What do you mean exactly with your last comment? I think that when distinctions in a domain are successfully made explicit at design time, this will improve performance at runtime and thus should also improve energy efficiency. How does that relate to your comment about message passing/branching/polymorphism? Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations jvalteren(a)objectguild.com On 13 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, wrote: > > > Hi StÃ©phane, > > > > Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. > > I do not know what is energy efficient nor how it is measurable. > Now our objectives is that pharo does not burn the batteries when doing nothing and we start to have that with the headless and idle vm. > > > For now, I think the efficiency will need to come from a good object design. > > this would presume that message passing is faster than branching. > And I remember that we had argument with hardware people about our reengineering pattern > on condition to polymorphism > > > > > > Kind regards, > > > > Jonathan van Alteren > > > > Founding Member | Object Guild B.V. > > Sustainable Software for Purpose-Driven Organizations > > > >

Oct. 13, 2020

Re: Energy efficiency of Pharo/Smalltalk

by StÃ©phane Ducasse

> Hi StÃ©phane, > > Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. I do not know what is energy efficient nor how it is measurable. Now our objectives is that pharo does not burn the batteries when doing nothing and we start to have that with the headless and idle vm. > For now, I think the efficiency will need to come from a good object design. this would presume that message passing is faster than branching. And I remember that we had argument with hardware people about our reengineering pattern on condition to polymorphism > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > Sustainable Software for Purpose-Driven Organizations > >

Oct. 13, 2020

Re: Standalone html builder (a la seaside without seaside?)

by Sean P. DeNigris

Jan BlizniÄenko wrote > ...HtmlDiv... Cool :) I've often felt a suspicion that the lack of logical HTML domain objects leaves a hole in the possibilities for declarative style / meta info ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 13, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Jonathan van Alteren

Hi StÃ©phane, Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. For now, I think the efficiency will need to come from a good object design. Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations On 11 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, wrote: > The problem is that what do you measure. > When you move computation from the CPU to a GPU for example does it consume less or more. > I think that such analyses are totally stupid. > Is a fast execution consume less? I have serious doubts about it. > Now if we measure how fast we drain a battery because of polling vs event based then this is different. > > S. > > > On 1 Oct 2020, at 13:47, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > > > Hi all, > > > > I am interested in energy efficiency metrics for Pharo (version >=8). Just now, I came across this research and related GitHub project: > > > > â¢ https://sites.google.com/view/energy-efficiency-languages > > â¢ https://github.com/greensoftwarelab/Energy-Languages > > > > > > Unfortunately, the paper mentions that Smalltalk was excluded from the results because the (VW) compiler was proprietary :-S However, the GitHub repository does contain Smalltalk code and results, but I haven't been able to evaluate those. > > > > [1] Does anyone here have more information on this topic? > > > > > > The benchmarks seem to be low-level algorithms. Although that is useful, I think that a better argument for Pharo/Smalltalk efficiency is that a good OO design (e.g. created using responsibility-driven design with behaviorally complete objects) will be a better fit, can be much simpler and will thus be more efficient during development, as well as easier to maintain and evolve. > > > > [2] Has anyone done any research in this area that can quantify this aspect? > > > > Kind regards, > > > > Jonathan van Alteren > > > > Founding Member | Object Guild B.V. > > Sustainable Software for Purpose-Driven Organizations > > > > jvalteren(a)objectguild.com > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Oct. 13, 2020

Re: [Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

by ducasse

Libgit depends on PCRE. O_o > On 13 Oct 2020, at 10:20, tesonep(a)gmail.com wrote: > > Hi Martin, > thanks for testing it. Can you tell me the version / flavour of > Debian are you using? > Maybe we need to ship PCRE with the VM. I am not fun of that, but we > need to do it until we can have a proper packaging for each Linux > distribution (Esteban is working on having a nice OBS configuration > for the VM extending what Holger has previously done). > It takes time and a lot of testing, but the idea is to fix (or at > least control better) the dependency nightmare between different Linux > distributions. > > Cheers, > Pablo > > On Tue, Oct 13, 2020 at 7:49 AM Martin McClure <martin(a)hand2mouse.com> wrote: >> >> Thanks, this is great news. >> >> Are there instructions on how to make P9 actually use the new version of >> libgit2? I see that the stable Linux VM for 9.0 does include >> "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. >> >> ...this may be because Pharo's libgit2.1.0.0.so has not-found >> dependencies on libpcre.so.3 and libpcreposix.so.3. >> >> I find Debian's versioning of libpcre somewhat confusing. The package >> "libpcre3" is the *old* libraries, and new stuff is supposed to use >> "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming >> is rather distro-specific, and although I have the right packages >> installed, the libraries have different filenames. >> >> But libgit2 is not supposed to have PCRE as a dependency. The source >> code for PCRE is included in the source for libgit2. Seems like it would >> be possible (and nice!) to compile the libgit2.1.0.0.so included with >> the VM to include the PCRE code internally, rather than depend on an >> external library. >> >> Thanks, >> -Martin >> >> On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: >>> Hi, a later announcement (this have been done some months ago... but I >>> never send the mail). >>> >>> We have upgraded in Pharo 9 to use the latest stable version of Libgit. >>> It required to have some improvements in Libgit to handle the updated >>> version and also to support the previous version. >>> >>> From the point of view of new features, it does not add new things. >>> However, this version fixes a lot of existing problems in Libgit. >>> >>> We can be sure this was a successful deployment as we don't have >>> problems with it. We are really happy that this has been done >>> transparently and keeping the working version with different >>> configurations of images and VMs. As we should support new and old >>> images, on the same VM. And also running new images in old VMs >>> >>> Thanks. >>> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com

Oct. 13, 2020

Re: [Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

by tesonep＠gmail.com

Hi Martin, thanks for testing it. Can you tell me the version / flavour of Debian are you using? Maybe we need to ship PCRE with the VM. I am not fun of that, but we need to do it until we can have a proper packaging for each Linux distribution (Esteban is working on having a nice OBS configuration for the VM extending what Holger has previously done). It takes time and a lot of testing, but the idea is to fix (or at least control better) the dependency nightmare between different Linux distributions. Cheers, Pablo On Tue, Oct 13, 2020 at 7:49 AM Martin McClure <martin(a)hand2mouse.com> wrote: > > Thanks, this is great news. > > Are there instructions on how to make P9 actually use the new version of > libgit2? I see that the stable Linux VM for 9.0 does include > "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. > > ...this may be because Pharo's libgit2.1.0.0.so has not-found > dependencies on libpcre.so.3 and libpcreposix.so.3. > > I find Debian's versioning of libpcre somewhat confusing. The package > "libpcre3" is the *old* libraries, and new stuff is supposed to use > "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming > is rather distro-specific, and although I have the right packages > installed, the libraries have different filenames. > > But libgit2 is not supposed to have PCRE as a dependency. The source > code for PCRE is included in the source for libgit2. Seems like it would > be possible (and nice!) to compile the libgit2.1.0.0.so included with > the VM to include the PCRE code internally, rather than depend on an > external library. > > Thanks, > -Martin > > On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: > > Hi, a later announcement (this have been done some months ago... but I > > never send the mail). > > > > We have upgraded in Pharo 9 to use the latest stable version of Libgit. > > It required to have some improvements in Libgit to handle the updated > > version and also to support the previous version. > > > > From the point of view of new features, it does not add new things. > > However, this version fixes a lot of existing problems in Libgit. > > > > We can be sure this was a successful deployment as we don't have > > problems with it. We are really happy that this has been done > > transparently and keeping the working version with different > > configurations of images and VMs. As we should support new and old > > images, on the same VM. And also running new images in old VMs > > > > Thanks. > > > -- Pablo Tesone. tesonep(a)gmail.com

Oct. 13, 2020

Re: [Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

by Martin McClure

Thanks, this is great news. Are there instructions on how to make P9 actually use the new version of libgit2? I see that the stable Linux VM for 9.0 does include "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. ...this may be because Pharo's libgit2.1.0.0.so has not-found dependencies on libpcre.so.3 and libpcreposix.so.3. I find Debian's versioning of libpcre somewhat confusing. The package "libpcre3" is the *old* libraries, and new stuff is supposed to use "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming is rather distro-specific, and although I have the right packages installed, the libraries have different filenames. But libgit2 is not supposed to have PCRE as a dependency. The source code for PCRE is included in the source for libgit2. Seems like it would be possible (and nice!) to compile the libgit2.1.0.0.so included with the VM to include the PCRE code internally, rather than depend on an external library. Thanks, -Martin On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: > Hi, a later announcement (this have been done some months ago... but I > never send the mail). > > We have upgraded in Pharo 9 to use the latest stable version of Libgit. > It required to have some improvements in Libgit to handle the updated > version and also to support the previous version. > > From the point of view of new features, it does not add new things. > However, this version fixes a lot of existing problems in Libgit. > > We can be sure this was a successful deployment as we don't have > problems with it. We are really happy that this has been done > transparently and keeping the working version with different > configurations of images and VMs. As we should support new and old > images, on the same VM. And also running new images in old VMs > > Thanks. >

Oct. 13, 2020

[ANN] Libgit 1.0.0 in Pharo 9

by tesonep＠gmail.com

Hi, a later announcement (this have been done some months ago... but I never send the mail). We have upgraded in Pharo 9 to use the latest stable version of Libgit. It required to have some improvements in Libgit to handle the updated version and also to support the previous version. >From the point of view of new features, it does not add new things. However, this version fixes a lot of existing problems in Libgit. We can be sure this was a successful deployment as we don't have problems with it. We are really happy that this has been done transparently and keeping the working version with different configurations of images and VMs. As we should support new and old images, on the same VM. And also running new images in old VMs Thanks. -- Pablo Tesone. tesonep(a)gmail.com

Oct. 12, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by StÃ©phane Ducasse

Tim saving in STON is also nice :). S > On 6 Oct 2020, at 22:41, Tim Mackinnon <tim(a)testit.works> wrote: > > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. > > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ however, move too soon and you get bogged down with the details and you lose site of an MVP. > > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). I suppose this is where the Rails scaffolding was/is? such a jumpstart, you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > Tim > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: >> >> Sean, >> >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. >> >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) >> >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. >> >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. >> >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. >> >> But, hey, I said all of that before. >> >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. >> >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? >> >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. >> >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. >> >> Joachim >> >> >> >> >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >>> jtuchel wrote >>>> Sigh. Forget about the idea that it will be easy to switch your >>>> persistence later....I am not commenting on SimplePersistence here, I >>>> don't even know what it >>>> does or doesn't. >>> Joachim, >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune >>> of a project growing enough to force me to make those tough choices! For >>> SimplePersistence I will say that I view it as a way to *delay* making *any* >>> choices until you are forced to. It's really just a layer of sugar on top of >>> Fuel (it used to use the old school Squeak equivalent serialization >>> mechanism - I forget the name and that might still work). You tell it what >>> classes to serialize. Implement two methods for each class that get and set >>> the data, and then it saves the whole thing as one object graph. >>> >>> Tim, >>> If you use SimplePersistence, please keep me posted about your experience. >>> I'm happy to help. >>> >>> NB I have maintained and extended the library, but it is the work of Ramon >>> Leon >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: [Pharo-dev] [ANN] Pharo Consortium New Gold Member: InfOil

by StÃ©phane Ducasse

us too :) S. > On 30 Sep 2020, at 16:39, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > As a former employee of the company I'm really happy to see this > finally happening! > > Best regards! > > Esteban A. Maringolo > > On Wed, Sep 30, 2020 at 11:13 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> The Pharo Consortium is very happy to announce that InfOil has joined the Consortium as a Gold Member. >> >> InfOil is an Argentinian company focused on software development for the Oil and Gas industry with clients >> in Latin America, Cuba, and Canada. >> >> About >> - InfOil: http://www.infoil.com.ar >> - Pharo Consortium: http://consortium.pharo.org >> >> The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development >> and future of Pharo. >> >> Individuals can support Pharo via the Pharo Association: >> >> - http://association.pharo.org -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: AthensCairoSDLSurface P8 Error

by StÃ©phane Ducasse

Hello alvaro can you try with P9 because we got many improvements. S > On 18 Sep 2020, at 22:07, Alvaro Piorno <alvaropiorno100(a)gmail.com> wrote: > > Hello, > > This code that worked for P6 and P7 is now failing in P8. > > AthensCairoSDLSurface fromSDLSurface: self window handle handle getWindowSurface. > > the window is created like this: > > window := OSWindow createWithAttributes: (OSWindowAttributes new resizable: false; yourself). > > The exception is Error: Could not coerce arguments > > from cairo lib. > > > Cheers -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: Standalone html builder (a la seaside without seaside?)

by StÃ©phane Ducasse

Hi jan can you do a PR to add eleven to the awesome list? S > On 29 Sep 2020, at 10:37, Jan BlizniÄenko <jan.bliznicenko(a)fit.cvut.cz> wrote: > > Hello, > > I am using https://github.com/JanBliznicenko/eleven for one of my projects. > It is also a full framework, yet much simplier than Seaside and stateless > and I believe only the HTML building functionality can be used indpendently. > > Example: > htmlObject := HtmlBody > with: > (HtmlDiv > class: 'content' > with: > (HtmlAnchor new > href: 'https://pharo.org'; > targetBlank; > with: 'Pharo website'; > yourself)). > String streamContents: [:stream | htmlObject renderFor: nil on: stream] > > The nil I am passing in the last line is there in place of an ELRequest > entity and is not needed for simple HTML tags without custom components. You > might check it out. Be aware that my former colleague created it for our > specific project and I have never used it in any other place, so I just HOPE > it would work like I imagine. It is also not documented or tested at all. > > Best regards, > Jan > > > Tim Mackinnon wrote >> Hi - has anyone ever managed to extract the html builder out of seaside - >> or written something equivalent? >> >> I often find I want to build some HTML, but donât want the full seaside - >> and was wondering if anyone has managed to extract it, or have something >> similar? >> >> This combined with Renoir from BA-ST would give a good little light weight >> web potential to run with Zinc. >> >> Tim > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: Standalone html builder (a la seaside without seaside?)

by StÃ©phane Ducasse

if someone migrate it to github please let me know. S > On 28 Sep 2020, at 20:35, Franz Josef Konrad <franzl(a)fjkonrad.de> wrote: > > Am 28.09.2020 um 19:28 schrieb Tim Mackinnon: >> Hi - has anyone ever managed to extract the html builder out of seaside - or written something equivalent? >> I often find I want to build some HTML, but donât want the full seaside - and was wondering if anyone has managed to extract it, or have something similar? >> This combined with Renoir from BA-ST would give a good little light weight web potential to run with Zinc. >> Tim > > Some years ago I was looking for something for the same purpose and looked at this library <http://smalltalkhub.com/PierceNg/WaterMint-HTML/index.html> <http://forum.world.st/Standalone-HTML-Model-td4967128.html> . I don't know if this helps. I also just loaded WaterMint and looked at the code. Other than that I had no experience. > > Franz Josef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: Energy efficiency of Pharo/Smalltalk

by StÃ©phane Ducasse

The problem is that what do you measure. When you move computation from the CPU to a GPU for example does it consume less or more. I think that such analyses are totally stupid. Is a fast execution consume less? I have serious doubts about it. Now if we measure how fast we drain a battery because of polling vs event based then this is different. S. > On 1 Oct 2020, at 13:47, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > Hi all, > > I am interested in energy efficiency metrics for Pharo (version >=8). Just now, I came across this research and related GitHub project: > https://sites.google.com/view/energy-efficiency-languages <https://sites.google.com/view/energy-efficiency-languages> > https://github.com/greensoftwarelab/Energy-Languages <https://github.com/greensoftwarelab/Energy-Languages> > > Unfortunately, the paper mentions that Smalltalk was excluded from the results because the (VW) compiler was proprietary :-S However, the GitHub repository does contain Smalltalk code and results, but I haven't been able to evaluate those. > > [1] Does anyone here have more information on this topic? > > > The benchmarks seem to be low-level algorithms. Although that is useful, I think that a better argument for Pharo/Smalltalk efficiency is that a good OO design (e.g. created using responsibility-driven design with behaviorally complete objects) will be a better fit, can be much simpler and will thus be more efficient during development, as well as easier to maintain and evolve. > > [2] Has anyone done any research in this area that can quantify this aspect? > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > Sustainable Software for Purpose-Driven Organizations > > jvalteren(a)objectguild.com -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Eduardo de Oliveira Padoan

Tim's original question is something that I ask myself from time to time. Having some "obvious" options for simple prototyping of ideas on Pharo would be a good tool for infiltrating Pharo in our workplaces and starting the slow adoption process. The Django web framework is a good example. The framework as a whole is quite complete, mature and professional, but it's adoption usually started with the auto-generated "admin" interface, an ill-suited tool for anything more serious. On Fri, Oct 9, 2020 at 12:53 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Tim, > > As I showed in my example Grafoscopio notebook in this thread, STON is a > pretty well suited format for complex documents or simple objects and > DVCS (Fossil / Git) friendly. Besides, the pretty print option make it > really readable, even outside Pharo (see the referred notebook for > example). Using Fossil repositories + STON as a future proof format for > reproducible, agile data storytelling is one of those combinations that, > could no be exactly what you're looking for, but maybe useful to have on > the radar and put in your preliminary explorations. I'm pretty happy > with it. > > Cheers, > > Offray > > On 9/10/20 6:07 a. m., Sven Van Caekenberghe wrote: > > > >> On 9 Oct 2020, at 12:13, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> > >> Tim Mackinnon wrote > >>> Thanks, I had completely forgotten about STON, thats a good point too > >>> (possibly this is what SimplePersistence uses as well - I'm not sure). > >> It currently uses Fuel, but the serializer/materializer is abstracted, > so > >> STON could probably be plugged in easily > > As a textual format, STON has the advantage that you can read/edit the > file (especially if you pretty print it). > > > > Wrapping a ZnBuffered[Read|Write]Stream around your text/character > stream before handing it to STON improves speed. > > > >> ----- > >> Cheers, > >> Sean > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -- Eduardo de Oliveira Padoan â®)

Oct. 9, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Offray Vladimir Luna CÃ¡rdenas

Tim, As I showed in my example Grafoscopio notebook in this thread, STON is a pretty well suited format for complex documents or simple objects and DVCS (Fossil / Git) friendly. Besides, the pretty print option make it really readable, even outside Pharo (see the referred notebook for example). Using Fossil repositories + STON as a future proof format for reproducible, agile data storytelling is one of those combinations that, could no be exactly what you're looking for, but maybe useful to have on the radar and put in your preliminary explorations. I'm pretty happy with it. Cheers, Offray On 9/10/20 6:07 a.Â m., Sven Van Caekenberghe wrote: > >> On 9 Oct 2020, at 12:13, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tim Mackinnon wrote >>> Thanks, I had completely forgotten about STON, thats a good point too >>> (possibly this is what SimplePersistence uses as well - I'm not sure). >> It currently uses Fuel, but the serializer/materializer is abstracted, so >> STON could probably be plugged in easily > As a textual format, STON has the advantage that you can read/edit the file (especially if you pretty print it). > > Wrapping a ZnBuffered[Read|Write]Stream around your text/character stream before handing it to STON improves speed. > >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Sven Van Caekenberghe

> On 9 Oct 2020, at 12:13, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> Thanks, I had completely forgotten about STON, thats a good point too >> (possibly this is what SimplePersistence uses as well - I'm not sure). > > It currently uses Fuel, but the serializer/materializer is abstracted, so > STON could probably be plugged in easily As a textual format, STON has the advantage that you can read/edit the file (especially if you pretty print it). Wrapping a ZnBuffered[Read|Write]Stream around your text/character stream before handing it to STON improves speed. > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Sean P. DeNigris

Tim Mackinnon wrote > Thanks, I had completely forgotten about STON, thats a good point too > (possibly this is what SimplePersistence uses as well - I'm not sure). It currently uses Fuel, but the serializer/materializer is abstracted, so STON could probably be plugged in easily ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Tim Mackinnon

Thanks, I had completely forgotten about STON, thats a good point too (possibly this is what SimplePersistence uses as well - I'm not sure). I recall there is a git repo for Pharo tips/tricks - I will try and curate this list over there as a few people have commented how useful this has been, and appreciate everyone who has chipped in. Tim On Thu, 8 Oct 2020, at 1:43 AM, Russ Whaley wrote: > I have been using STON for a while now. It does a really nice job of keeping everything just the way I need it - and the read/write - even for larger files process very quickly. Limitations are full writes, no updates, but hey, it is incredibly easy to use and works in both v8 and v9. I built a flashcard application in Pharo as well, and the STON files load in a fraction of a second. > > Cheers! > Russ > > On Wed, Oct 7, 2020 at 12:04 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >> Am 06.10.20 um 22:41 schrieb Tim Mackinnon: >> >> > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. >> >> > >> >> > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, >> >> >> >> yes, sounds like it. You mentioned it is not a super-complex 30-year >> >> project you are planning. It sounds like you can load all the data into >> >> memory in a few msec and just go form there, Saving the whole model as a >> >> file also sounds like perfectly doable in such a project. So, heck, you >> >> could probably simply just save the image and be good. A chunk of JSON, >> >> Fuel, whatever object serialization is probably second best. >> >> >> >> The great thing about this: nothing external (to the image) to install >> >> or maintain. It is just you and the file system. >> >> >> >> >> >> > however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ >> >> >> >> Oh no, don't fear this too much. That's not what I wanted to point out. >> >> Most projects will do well on either NoSQL or using an ORM or an OODB. >> >> Almost anything is possible on all of them. We do boring business stuff >> >> (accounting) using Glorp as an ORM and DB2. Another well-known project >> >> in the Pharo world does something extremely similar (travel cost) with >> >> Voyage/Mongo. It is not so much a question of lost opportunities. The >> >> problem here is that you have to deal with the very same problems >> >> (concurrent access and isolation, fast lookups, caching, ghost objects) >> >> on each of these technologies, but differently. It is the different >> >> approaches to the same problems that make switching from one to the >> >> other that makes the decision so hard. >> >> >> >> Example: we had a hard time finding out why some objects never went away >> >> although we had deleted them from the database. It took a while of >> >> logging all SQL statements until we found out first that they were >> >> really deleted in the Transaction when the user clicked OK. But they >> >> were inserted back in the next, possibly completely unrelated, >> >> transaction, because we had some dangling backpointers that tricked >> >> glorp into thinking "oops, there is this bunch of new objects I have to >> >> insert now". This is why I used object deletion as an example. Smalltalk >> >> has no concept of deleting an object. Databases do. So whatever approach >> >> you chose, deleting an object looks different. You either make the >> >> object completely (!) unreachable from the rest of the object model and >> >> thus just make it irrelevant, or you tell the databse to just throw it >> >> away. Sounds like no big deal. But it can be. >> >> >> >> >> >> >> >> > and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ >> >> The hard part here: the example with the reinserted objects is what is >> >> called an unknown unknown in the boringtech site ;-) You would need a >> >> test to check whether an object you deleted really isn't reoccuring >> >> after the next Transaction. You'd have to imagine that there might be a >> >> small chance that you delete an object successfully, but for some reason >> >> you distorted the ORMs internal bookkeeping and trocked it into >> >> inserting teh object back in some consecutive Transaction. A simple fact >> >> once you understood why it happened, but I am 99% sure almost nobody >> >> would come around the corner and say: well, we'll have to write a test >> >> for this scenario where an object still lingers somewhere and gets >> >> reinserted. The whole team would by this guy a beer and move to another >> >> table. >> >> > however, move too soon and you get bogged down with the details and you lose site of an MVP. >> >> >> >> move and live with your decision. Or be prepared for a much more >> >> complicated transition than you thought. >> >> >> >> The problem is that nobody (at least that I am aware of) has come up >> >> with an abstraction good enough to make the persistence implications >> >> irrelevant enough and provide good performance and feature richness at >> >> the same time. I know it's been tried. >> >> >> >> >> >> > >> >> > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). >> >> Not sure about the need for Docker. You just throw more tech at the >> >> problem. I mean, installing and setting up PostgreSQL or MySQL on a >> >> Linux distro these days is matter of a few commands. apt install, enter >> >> a db administrator password, answer a few questions and go. Same with >> >> Mongo or CouchDB. >> >> > I suppose this is where the Rails scaffolding was/is? such a jumpstart, >> >> >> >> Don't get me started ;-) >> >> >> >> Scaffolding is great if you need to sell a technology to management on a >> >> few slides. Slip in some comment like "works on existing database >> >> schemas too, at no extra cost" and these guys are ready to write >> >> whatever it takes onto a cheque. I mean, come on, that guy showed us how >> >> to make the whole mapping and transaction management for a flight >> >> booking system in 15 minutes, how much harder can our project be? That's >> >> how most multi-million desasters start. >> >> >> >> >> >> > you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. >> >> >> >> I totally agree. These days, everything is easy. Just install NodeJS and >> >> some super sophisticated package manager and let it install everything >> >> for you in just 5 minutes and you're ready to go. Just make sure you >> >> have at least 12 GB of free memory and a good machine with fast >> >> internet. Your data will be stored in the *bling, stars and glitter * >> >> Cloud and you just forget about this detail. You want a login screen, >> >> sure, just type 'init -n -tfgr "login"' and provide your github >> >> credentials. We'll create a directory structure for you with a src, an >> >> html, a helpers and a .gitignore file. Don't worry, some of that you'll >> >> never touch. Oh, sure just make sure you have a Facebook account and >> >> consent with the cookie policy of that super-georgous technology company >> >> that provides this piece of code. >> >> >> >> Not sure if that is what is really needed, but it's where we're heading >> >> at the moment. Open any JS related book these days and read the first >> >> chapter. I bet it's going to step you through the installation process >> >> of at least three major super-cool open source, reliable and tested >> >> frameworks or infrastructure monsters before you can start. From there >> >> on, everything is a breeze. It's like a free lunch. >> >> >> >> But boy, somebody will have to run this stuff for a while. >> >> >> >> I think the Smalltalk vendors, both commercial and open source are >> >> making great progress here, and I like the fact that we are not followng >> >> the bloating trend. Maybe the "not invented here" meme makes sense to >> >> some degree. What we as developers need is some understanding of what >> >> we're doing and not so much the latest bells and whistles. Storing data >> >> in a file may be unsophisticated, but it does the job even under hard >> >> conditions. >> >> >> >> ..but I am getting slightly off-topic ;-) >> >> >> >> >> >> Joachim >> >> >> >> >> >> >> >> > It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ >> >> > >> >> > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ >> >> > >> >> > Tim >> >> > >> >> >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: >> >> >> >> >> >> Sean, >> >> >> >> >> >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. >> >> >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. >> >> >> >> >> >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) >> >> >> >> >> >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. >> >> >> >> >> >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. >> >> >> >> >> >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. >> >> >> >> >> >> But, hey, I said all of that before. >> >> >> >> >> >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. >> >> >> >> >> >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? >> >> >> >> >> >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. >> >> >> >> >> >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. >> >> >> >> >> >> Joachim >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >> >> >>> jtuchel wrote >> >> >>>> Sigh. Forget about the idea that it will be easy to switch your >> >> >>>> persistence later....I am not commenting on SimplePersistence here, I >> >> >>>> don't even know what it >> >> >>>> does or doesn't. >> >> >>> Joachim, >> >> >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune >> >> >>> of a project growing enough to force me to make those tough choices! For >> >> >>> SimplePersistence I will say that I view it as a way to *delay* making *any* >> >> >>> choices until you are forced to. It's really just a layer of sugar on top of >> >> >>> Fuel (it used to use the old school Squeak equivalent serialization >> >> >>> mechanism - I forget the name and that might still work). You tell it what >> >> >>> classes to serialize. Implement two methods for each class that get and set >> >> >>> the data, and then it saves the whole thing as one object graph. >> >> >>> >> >> >>> Tim, >> >> >>> If you use SimplePersistence, please keep me posted about your experience. >> >> >>> I'm happy to help. >> >> >>> >> >> >>> NB I have maintained and extended the library, but it is the work of Ramon >> >> >>> Leon >> >> >>> >> >> >>> >> >> >>> >> >> >>> ----- >> >> >>> Cheers, >> >> >>> Sean >> >> >>> -- >> >> >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >>> >> >> >> -- >> >> >> ----------------------------------------------------------------------- >> >> >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> >> >> Fliederweg 1 http://www.objektfabrik.de >> >> >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> >> >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> >> >> >> >> >> -- >> >> ----------------------------------------------------------------------- >> >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> >> Fliederweg 1 http://www.objektfabrik.de >> >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > -- > Russ Whaley > whaley.russ(a)gmail.com

Oct. 9, 2020

Re: SmalltalkHub download problem

by bruno buzzi brassesco

Christophe/Marcus, It is working now. Thank you !!! regards, Bruno On 8/10/2020 06:13, Marcus Denker wrote: > > >> On 8 Oct 2020, at 09:04, Christophe Demarey >> <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: >> >> Hi Bruno, >> >>> Le 7 oct. 2020 Ã 20:08, bruno buzzi brassesco >>> <smalltalk(a)adinet.com.uy <mailto:smalltalk@adinet.com.uy>> a Ã©crit : >>> >>> Hi, >>> >>> Trying to download: >>> http://www.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-… >>> or: >>> http://deprecated.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationO… >>> >>> An error arise: >>> VOMongoConnectionError >>> >>> Any idea what is going on ? MongoDB down ? >>> >> >> You can use this link: >> http://smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-mont… >> It looks like there is a missing DNS entry update >> forwww.smalltalkhub.com <http://www.smalltalkhub.com/>. > > I fixed the DNS entry > > Marcus >

Oct. 8, 2020

Re: SmalltalkHub download problem

by Marcus Denker

> On 8 Oct 2020, at 09:04, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Bruno, > >> Le 7 oct. 2020 Ã 20:08, bruno buzzi brassesco <smalltalk(a)adinet.com.uy <mailto:smalltalk@adinet.com.uy>> a Ã©crit : >> >> Hi, >> >> Trying to download: >> http://www.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-… <http://www.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-…> >> or: >> http://deprecated.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationO… <http://deprecated.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationO…> >> An error arise: >> VOMongoConnectionError >> >> Any idea what is going on ? MongoDB down ? >> > > You can use this link: http://smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-mont… <http://smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-mont…> > It looks like there is a missing DNS entry update for www.smalltalkhub.com <http://www.smalltalkhub.com/>. I fixed the DNS entry Marcus

Oct. 8, 2020

Re: SmalltalkHub download problem

by Christophe Demarey

Hi Bruno, > Le 7 oct. 2020 Ã 20:08, bruno buzzi brassesco <smalltalk(a)adinet.com.uy> a Ã©crit : > > Hi, > > Trying to download: > http://www.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-… <http://www.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-…> > or: > http://deprecated.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationO… <http://deprecated.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationO…> > An error arise: > VOMongoConnectionError > > Any idea what is going on ? MongoDB down ? > You can use this link: http://smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-mont… It looks like there is a missing DNS entry update for www.smalltalkhub.com. The deprecated version will be killed at the end of the month. Thanks for the notification. Regards, Christophe

Oct. 8, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Russ Whaley

I have been using STON for a while now. It does a really nice job of keeping everything just the way I need it - and the read/write - even for larger files process very quickly. Limitations are full writes, no updates, but hey, it is incredibly easy to use and works in both v8 and v9. I built a flashcard application in Pharo as well, and the STON files load in a fraction of a second. Cheers! Russ On Wed, Oct 7, 2020 at 12:04 AM jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Am 06.10.20 um 22:41 schrieb Tim Mackinnon: > > > Gosh - this is proving much more interesting than I had imagined, and > Iâm getting lots of useful input, so I double appreciate the time and > thoughts from everyone. > > > > > > I probably should have said that my "super awesome idea" is just a > little flashcard spelling app for my daughter (and possibly a few friends > in her class) - so probably SimplePersistance will do in this case, > > > > yes, sounds like it. You mentioned it is not a super-complex 30-year > > project you are planning. It sounds like you can load all the data into > > memory in a few msec and just go form there, Saving the whole model as a > > file also sounds like perfectly doable in such a project. So, heck, you > > could probably simply just save the image and be good. A chunk of JSON, > > Fuel, whatever object serialization is probably second best. > > > > The great thing about this: nothing external (to the image) to install > > or maintain. It is just you and the file system. > > > > > > > however the comments about making a persistence decision at the right > moment are super interesting - and as always, its about spotting the right > moment to do thatâ¦ > > > > Oh no, don't fear this too much. That's not what I wanted to point out. > > Most projects will do well on either NoSQL or using an ORM or an OODB. > > Almost anything is possible on all of them. We do boring business stuff > > (accounting) using Glorp as an ORM and DB2. Another well-known project > > in the Pharo world does something extremely similar (travel cost) with > > Voyage/Mongo. It is not so much a question of lost opportunities. The > > problem here is that you have to deal with the very same problems > > (concurrent access and isolation, fast lookups, caching, ghost objects) > > on each of these technologies, but differently. It is the different > > approaches to the same problems that make switching from one to the > > other that makes the decision so hard. > > > > Example: we had a hard time finding out why some objects never went away > > although we had deleted them from the database. It took a while of > > logging all SQL statements until we found out first that they were > > really deleted in the Transaction when the user clicked OK. But they > > were inserted back in the next, possibly completely unrelated, > > transaction, because we had some dangling backpointers that tricked > > glorp into thinking "oops, there is this bunch of new objects I have to > > insert now". This is why I used object deletion as an example. Smalltalk > > has no concept of deleting an object. Databases do. So whatever approach > > you chose, deleting an object looks different. You either make the > > object completely (!) unreachable from the rest of the object model and > > thus just make it irrelevant, or you tell the databse to just throw it > > away. Sounds like no big deal. But it can be. > > > > > > > > > and ideally you have well factored code with ample tests that help you > easily move from the idea, to something more scalable or robustâ¦ > > The hard part here: the example with the reinserted objects is what is > > called an unknown unknown in the boringtech site ;-) You would need a > > test to check whether an object you deleted really isn't reoccuring > > after the next Transaction. You'd have to imagine that there might be a > > small chance that you delete an object successfully, but for some reason > > you distorted the ORMs internal bookkeeping and trocked it into > > inserting teh object back in some consecutive Transaction. A simple fact > > once you understood why it happened, but I am 99% sure almost nobody > > would come around the corner and say: well, we'll have to write a test > > for this scenario where an object still lingers somewhere and gets > > reinserted. The whole team would by this guy a beer and move to another > > table. > > > however, move too soon and you get bogged down with the details and you > lose site of an MVP. > > > > move and live with your decision. Or be prepared for a much more > > complicated transition than you thought. > > > > The problem is that nobody (at least that I am aware of) has come up > > with an abstraction good enough to make the persistence implications > > irrelevant enough and provide good performance and feature richness at > > the same time. I know it's been tried. > > > > > > > > > > It has been interesting hearing peoples thoughts on all of thisâ¦ the > turning tide on ORMâs, the potential sweet allure of a NoSql (but can you > query it easily) - and then the overarching element of just setting this > shit up (where hopefully Docker steps in to make that bit at least easy). > > Not sure about the need for Docker. You just throw more tech at the > > problem. I mean, installing and setting up PostgreSQL or MySQL on a > > Linux distro these days is matter of a few commands. apt install, enter > > a db administrator password, answer a few questions and go. Same with > > Mongo or CouchDB. > > > I suppose this is where the Rails scaffolding was/is? such a jumpstart, > > > > Don't get me started ;-) > > > > Scaffolding is great if you need to sell a technology to management on a > > few slides. Slip in some comment like "works on existing database > > schemas too, at no extra cost" and these guys are ready to write > > whatever it takes onto a cheque. I mean, come on, that guy showed us how > > to make the whole mapping and transaction management for a flight > > booking system in 15 minutes, how much harder can our project be? That's > > how most multi-million desasters start. > > > > > > > you can get a full thing going quite easily, and deploying seems > relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much > work for my liking, compared to the ease of getting an image and coding, > and seeing it all work. > > > > I totally agree. These days, everything is easy. Just install NodeJS and > > some super sophisticated package manager and let it install everything > > for you in just 5 minutes and you're ready to go. Just make sure you > > have at least 12 GB of free memory and a good machine with fast > > internet. Your data will be stored in the *bling, stars and glitter * > > Cloud and you just forget about this detail. You want a login screen, > > sure, just type 'init -n -tfgr "login"' and provide your github > > credentials. We'll create a directory structure for you with a src, an > > html, a helpers and a .gitignore file. Don't worry, some of that you'll > > never touch. Oh, sure just make sure you have a Facebook account and > > consent with the cookie policy of that super-georgous technology company > > that provides this piece of code. > > > > Not sure if that is what is really needed, but it's where we're heading > > at the moment. Open any JS related book these days and read the first > > chapter. I bet it's going to step you through the installation process > > of at least three major super-cool open source, reliable and tested > > frameworks or infrastructure monsters before you can start. From there > > on, everything is a breeze. It's like a free lunch. > > > > But boy, somebody will have to run this stuff for a while. > > > > I think the Smalltalk vendors, both commercial and open source are > > making great progress here, and I like the fact that we are not followng > > the bloating trend. Maybe the "not invented here" meme makes sense to > > some degree. What we as developers need is some understanding of what > > we're doing and not so much the latest bells and whistles. Storing data > > in a file may be unsophisticated, but it does the job even under hard > > conditions. > > > > ..but I am getting slightly off-topic ;-) > > > > > > Joachim > > > > > > > > > It does seem to be getting marginally better at least, but I do wish > there was super easy setup with all the pieces nicely in place so it was > just your idea that you could focus onâ¦ > > > > > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > > > > > Tim > > > > > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: > > >> > > >> Sean, > > >> > > >> thanks for your short overview of what SimplePersistence does. Sounds > useful for quite a few scenarios and might even carry you well through > production stages for some projects. > > >> What I was talking about is also not meant to frustrate people. I've > only played with Mongo/Voyage for a few hours and I must say I was blown > away by the speed and ease of that stack. We got something running in a few > hours and it was impressive. So Mongo/Voyage is a cool thing to use. > > >> > > >> I always wanted to use Magna on Pharo. I even started to implement my > own little clone of Magna in VA Smalltalk. I got into troubles when I tried > to nest transactions and get this concurrency stuff streamlined somehow. We > all know that besides naming and one-off problems, caching and concurreny > are the hardest problems in computing. I think there is something about > this. And so I gave up on that project... ;-) > > >> > > >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in > a very solid state somewhere between complete despair and freaking out > about how cool things are. I love and hate that stack from the bottom of my > heart. > > >> > > >> The cool thing about an RDB is (and will sure be for quite a while) > three letters. S, Q and L. There are lots of highly sophisticated GUI tools > to query, manage, correct your data. And you can simply do everything form > a command prompt, in an ssh session from your smartphone in a hotel toilet > on the other side of the planet. > > >> > > >> Sure, using pure Smalltalk objects and not worry about n:m > relationships, not having to write mappings and not having to end up with > an object model that is driven mostly by what your O/R mapper can handle, > sound great. And it is. Until you realize you also need to think about > query optimizations, reorganizations, indexes and whatnot in an object > database. There are also compromises to make. > > >> > > >> But, hey, I said all of that before. > > >> > > >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object > Swapper) are the best thing to start with when you need to find out about > your architectural and business ideas first (am I building the right thing, > will this feel good to a user, etc.), but once you are beyond that state, > you better dive into your options and decide soon. Maybe using image saving > or SimplePersistence is even good for production in your case. It was good > enough for dabbleDB for quite a while, iirc, so why shouldn't it work for > others? And maybe that is even the best you can do to postpone the decision > for as long as possible at minimum opportunity cost. > > >> > > >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or > risky the changes to the design are. How hard is it to restructure the root > trees - say you need something that is now beneath some root to be a root > of its own? How would you do such changes? > > >> > > >> I know I can do a lot of things of that kind with SQL. It is a second > looking glass and set of tools to view and manipulate the data. Sometimes > things are easier to do in Smalltalk, sometimes it is way too slow on top > of an ORM and a SQL query can do the same thing in a few milliseconds. > > >> > > >> But maybe I am asking the wrong questions fo Tim's purposes. I think I > understand what you (Tim) are looking for is not a big, complex project but > more like an experiment? I don't want to invalidate any of the given > suggestions, I know or at least believe that they each do a good job. All I > really wanted to warn you is that you will not easily be able to go from > one option to another, because each will have a deep impact on your object > model and application architecture. > > >> > > >> Joachim > > >> > > >> > > >> > > >> > > >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: > > >>> jtuchel wrote > > >>>> Sigh. Forget about the idea that it will be easy to switch your > > >>>> persistence later....I am not commenting on SimplePersistence here, I > > >>>> don't even know what it > > >>>> does or doesn't. > > >>> Joachim, > > >>> Thanks for this interesting perspective. I've never had the > (mis?!)fortune > > >>> of a project growing enough to force me to make those tough choices! > For > > >>> SimplePersistence I will say that I view it as a way to *delay* making > *any* > > >>> choices until you are forced to. It's really just a layer of sugar on > top of > > >>> Fuel (it used to use the old school Squeak equivalent serialization > > >>> mechanism - I forget the name and that might still work). You tell it > what > > >>> classes to serialize. Implement two methods for each class that get > and set > > >>> the data, and then it saves the whole thing as one object graph. > > >>> > > >>> Tim, > > >>> If you use SimplePersistence, please keep me posted about your > experience. > > >>> I'm happy to help. > > >>> > > >>> NB I have maintained and extended the library, but it is the work of > Ramon > > >>> Leon > > >>> > > >>> > > >>> > > >>> ----- > > >>> Cheers, > > >>> Sean > > >>> -- > > >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > >>> > > >> -- > > >> ----------------------------------------------------------------------- > > >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > > >> Fliederweg 1 http://www.objektfabrik.de > > >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > > >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >> > > > > -- > > ----------------------------------------------------------------------- > > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > > Fliederweg 1 http://www.objektfabrik.de > > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > > -- Russ Whaley whaley.russ(a)gmail.com

Oct. 8, 2020

[ANN] HighchartsSt v12.1.1 [v12.1.1] released!

by Buenos Aires Smalltalk

Oct. 7, 2020

SmalltalkHub download problem

by bruno buzzi brassesco

Hi, Trying to download: http://www.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationOfXPath-… or: http://deprecated.smalltalkhub.com/mc/PharoExtras/XPath/main/ConfigurationO… An error arise: VOMongoConnectionError Any idea what is going on ? MongoDB down ? regards, bruno

Oct. 7, 2020

Re: [Offtopic] Documentary Project

by Marcus Denker

Hi! This looks *really* nice! I really hope you will succeed with the kickstarter! I have supported it and tweetet a link. I will put it in the pharo tweet queue, too. Marcus > On 6 Oct 2020, at 19:19, Eric Gade <eric.gade(a)gmail.com> wrote: > > Fellow Squeakers and Pharo-ers, > > Please forgive me if this message is inappropriate for the list. I am hoping you all will be interested in the following project. > > For the past year and a half I have been working on a team that is developing a documentary <https://www.kickstarter.com/projects/messagenotunderstood/message-not-under…> on the history of personal computing. Our goal is to interview the very people who laid the foundations for personal computing while they are still with us, learning about their original visions and getting their take on the present. In this sense it is both an aspiring feature length documentary project but also an endeavor in oral history and posterity. Many of the themes we want to explore will be familiar to the members of this community (as will the title). > > Last fall we were able to shoot our first three interviews. We used these to make a short teaser <https://vimeo.com/429045920>, with the idea it could be used to raise funds for future rounds of interviews. That said, we are currently in the middle of a Kickstarter campaign <https://www.kickstarter.com/projects/messagenotunderstood/message-not-under…> to get the second round funded. If you are interested in learning more, feel free to reach out to me directly and to visit the film's campaign site <https://www.kickstarter.com/projects/messagenotunderstood/message-not-under…> and website <https://messagenotunderstood.com/>. We need all the promotion we can get! > > Thanks! > > > -- > Eric

Oct. 7, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Tim Mackinnon

Joachim - thanks again for adding more insight, have learned (and been reminded) at lot from this thread - and certainly have a few paths forward with some suitable warnings too. As my project is a "spare time" one, I can at least enjoy the journey and test some of this out. Tim On Wed, 7 Oct 2020, at 5:04 AM, jtuchel(a)objektfabrik.de wrote: > Am 06.10.20 um 22:41 schrieb Tim Mackinnon: > > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. > > > > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, > > yes, sounds like it. You mentioned it is not a super-complex 30-year > project you are planning. It sounds like you can load all the data into > memory in a few msec and just go form there, Saving the whole model as a > file also sounds like perfectly doable in such a project. So, heck, you > could probably simply just save the image and be good. A chunk of JSON, > Fuel, whatever object serialization is probably second best. > > The great thing about this: nothing external (to the image) to install > or maintain. It is just you and the file system. > > > > however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ > > Oh no, don't fear this too much. That's not what I wanted to point out. > Most projects will do well on either NoSQL or using an ORM or an OODB. > Almost anything is possible on all of them. We do boring business stuff > (accounting) using Glorp as an ORM and DB2. Another well-known project > in the Pharo world does something extremely similar (travel cost) with > Voyage/Mongo. It is not so much a question of lost opportunities. The > problem here is that you have to deal with the very same problems > (concurrent access and isolation, fast lookups, caching, ghost objects) > on each of these technologies, but differently. It is the different > approaches to the same problems that make switching from one to the > other that makes the decision so hard. > > Example: we had a hard time finding out why some objects never went away > although we had deleted them from the database. It took a while of > logging all SQL statements until we found out first that they were > really deleted in the Transaction when the user clicked OK. But they > were inserted back in the next, possibly completely unrelated, > transaction, because we had some dangling backpointers that tricked > glorp into thinking "oops, there is this bunch of new objects I have to > insert now". This is why I used object deletion as an example. Smalltalk > has no concept of deleting an object. Databases do. So whatever approach > you chose, deleting an object looks different. You either make the > object completely (!) unreachable from the rest of the object model and > thus just make it irrelevant, or you tell the databse to just throw it > away. Sounds like no big deal. But it can be. > > > > > and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ > The hard part here: the example with the reinserted objects is what is > called an unknown unknown in the boringtech site ;-) You would need a > test to check whether an object you deleted really isn't reoccuring > after the next Transaction. You'd have to imagine that there might be a > small chance that you delete an object successfully, but for some reason > you distorted the ORMs internal bookkeeping and trocked it into > inserting teh object back in some consecutive Transaction. A simple fact > once you understood why it happened, but I am 99% sure almost nobody > would come around the corner and say: well, we'll have to write a test > for this scenario where an object still lingers somewhere and gets > reinserted. The whole team would by this guy a beer and move to another > table. > > however, move too soon and you get bogged down with the details and you lose site of an MVP. > > move and live with your decision. Or be prepared for a much more > complicated transition than you thought. > > The problem is that nobody (at least that I am aware of) has come up > with an abstraction good enough to make the persistence implications > irrelevant enough and provide good performance and feature richness at > the same time. I know it's been tried. > > > > > > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). > Not sure about the need for Docker. You just throw more tech at the > problem. I mean, installing and setting up PostgreSQL or MySQL on a > Linux distro these days is matter of a few commands. apt install, enter > a db administrator password, answer a few questions and go. Same with > Mongo or CouchDB. > > I suppose this is where the Rails scaffolding was/is? such a jumpstart, > > Don't get me started ;-) > > Scaffolding is great if you need to sell a technology to management on a > few slides. Slip in some comment like "works on existing database > schemas too, at no extra cost" and these guys are ready to write > whatever it takes onto a cheque. I mean, come on, that guy showed us how > to make the whole mapping and transaction management for a flight > booking system in 15 minutes, how much harder can our project be? That's > how most multi-million desasters start. > > > > you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. > > I totally agree. These days, everything is easy. Just install NodeJS and > some super sophisticated package manager and let it install everything > for you in just 5 minutes and you're ready to go. Just make sure you > have at least 12 GB of free memory and a good machine with fast > internet. Your data will be stored in the *bling, stars and glitter * > Cloud and you just forget about this detail. You want a login screen, > sure, just type 'init -n -tfgr "login"' and provide your github > credentials. We'll create a directory structure for you with a src, an > html, a helpers and a .gitignore file. Don't worry, some of that you'll > never touch. Oh, sure just make sure you have a Facebook account and > consent with the cookie policy of that super-georgous technology company > that provides this piece of code. > > Not sure if that is what is really needed, but it's where we're heading > at the moment. Open any JS related book these days and read the first > chapter. I bet it's going to step you through the installation process > of at least three major super-cool open source, reliable and tested > frameworks or infrastructure monsters before you can start. From there > on, everything is a breeze. It's like a free lunch. > > But boy, somebody will have to run this stuff for a while. > > I think the Smalltalk vendors, both commercial and open source are > making great progress here, and I like the fact that we are not followng > the bloating trend. Maybe the "not invented here" meme makes sense to > some degree. What we as developers need is some understanding of what > we're doing and not so much the latest bells and whistles. Storing data > in a file may be unsophisticated, but it does the job even under hard > conditions. > > ..but I am getting slightly off-topic ;-) > > > Joachim > > > > > It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ > > > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > > > Tim > > > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: > >> > >> Sean, > >> > >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. > >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. > >> > >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) > >> > >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. > >> > >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. > >> > >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. > >> > >> But, hey, I said all of that before. > >> > >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. > >> > >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? > >> > >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. > >> > >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. > >> > >> Joachim > >> > >> > >> > >> > >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: > >>> jtuchel wrote > >>>> Sigh. Forget about the idea that it will be easy to switch your > >>>> persistence later....I am not commenting on SimplePersistence here, I > >>>> don't even know what it > >>>> does or doesn't. > >>> Joachim, > >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune > >>> of a project growing enough to force me to make those tough choices! For > >>> SimplePersistence I will say that I view it as a way to *delay* making *any* > >>> choices until you are forced to. It's really just a layer of sugar on top of > >>> Fuel (it used to use the old school Squeak equivalent serialization > >>> mechanism - I forget the name and that might still work). You tell it what > >>> classes to serialize. Implement two methods for each class that get and set > >>> the data, and then it saves the whole thing as one object graph. > >>> > >>> Tim, > >>> If you use SimplePersistence, please keep me posted about your experience. > >>> I'm happy to help. > >>> > >>> NB I have maintained and extended the library, but it is the work of Ramon > >>> Leon > >>> > >>> > >>> > >>> ----- > >>> Cheers, > >>> Sean > >>> -- > >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >>> > >> -- > >> ----------------------------------------------------------------------- > >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > >> Fliederweg 1 http://www.objektfabrik.de > >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >> > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

Oct. 7, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by jtuchel＠objektfabrik.de

Am 06.10.20 um 22:41 schrieb Tim Mackinnon: > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. > > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, yes, sounds like it. You mentioned it is not a super-complex 30-year project you are planning. It sounds like you can load all the data into memory in a few msec and just go form there, Saving the whole model as a file also sounds like perfectly doable in such a project. So, heck, you could probably simply just save the image and be good. A chunk of JSON, Fuel, whatever object serialization is probably second best. The great thing about this: nothing external (to the image) to install or maintain. It is just you and the file system. > however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ Oh no, don't fear this too much. That's not what I wanted to point out. Most projects will do well on either NoSQL or using an ORM or an OODB. Almost anything is possible on all of them. We do boring business stuff (accounting) using Glorp as an ORM and DB2. Another well-known project in the Pharo world does something extremely similar (travel cost) with Voyage/Mongo. It is not so much a question of lost opportunities. The problem here is that you have to deal with the very same problems (concurrent access and isolation, fast lookups, caching, ghost objects) on each of these technologies, but differently. It is the different approaches to the same problems that make switching from one to the other that makes the decision so hard. Example: we had a hard time finding out why some objects never went away although we had deleted them from the database. It took a while of logging all SQL statements until we found out first that they were really deleted in the Transaction when the user clicked OK. But they were inserted back in the next, possibly completely unrelated, transaction, because we had some dangling backpointers that tricked glorp into thinking "oops, there is this bunch of new objects I have to insert now". This is why I used object deletion as an example. Smalltalk has no concept of deleting an object. Databases do. So whatever approach you chose, deleting an object looks different. You either make the object completely (!) unreachable from the rest of the object model and thus just make it irrelevant, or you tell the databse to just throw it away. Sounds like no big deal. But it can be. > and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ The hard part here: the example with the reinserted objects is what is called an unknown unknown in the boringtech site ;-) You would need a test to check whether an object you deleted really isn't reoccuring after the next Transaction. You'd have to imagine that there might be a small chance that you delete an object successfully, but for some reason you distorted the ORMs internal bookkeeping and trocked it into inserting teh object back in some consecutive Transaction. A simple fact once you understood why it happened, but I am 99% sure almost nobody would come around the corner and say: well, we'll have to write a test for this scenario where an object still lingers somewhere and gets reinserted. The whole team would by this guy a beer and move to another table. > however, move too soon and you get bogged down with the details and you lose site of an MVP. move and live with your decision. Or be prepared for a much more complicated transition than you thought. The problem is that nobody (at least that I am aware of) has come up with an abstraction good enough to make the persistence implications irrelevant enough and provide good performance and feature richness at the same time. I know it's been tried. > > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). Not sure about the need for Docker. You just throw more tech at the problem. I mean, installing and setting up PostgreSQL or MySQL on a Linux distro these days is matter of a few commands. apt install, enter a db administrator password, answer a few questions and go. Same with Mongo or CouchDB. > I suppose this is where the Rails scaffolding was/is? such a jumpstart, Don't get me started ;-) Scaffolding is great if you need to sell a technology to management on a few slides. Slip in some comment like "works on existing database schemas too, at no extra cost" and these guys are ready to write whatever it takes onto a cheque. I mean, come on, that guy showed us how to make the whole mapping and transaction management for a flight booking system in 15 minutes, how much harder can our project be? That's how most multi-million desasters start. > you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. I totally agree. These days, everything is easy. Just install NodeJS and some super sophisticated package manager and let it install everything for you in just 5 minutes and you're ready to go. Just make sure you have at least 12 GB of free memory and a good machine with fast internet. Your data will be stored in the *bling, stars and glitter * Cloud and you just forget about this detail. You want a login screen, sure, just type 'init -n -tfgr "login"' and provide your github credentials. We'll create a directory structure for you with a src, an html, a helpers and a .gitignore file. Don't worry, some of that you'll never touch. Oh, sure just make sure you have a Facebook account and consent with the cookie policy of that super-georgous technology company that provides this piece of code. Not sure if that is what is really needed, but it's where we're heading at the moment. Open any JS related book these days and read the first chapter. I bet it's going to step you through the installation process of at least three major super-cool open source, reliable and tested frameworks or infrastructure monsters before you can start. From there on, everything is a breeze. It's like a free lunch. But boy, somebody will have to run this stuff for a while. I think the Smalltalk vendors, both commercial and open source are making great progress here, and I like the fact that we are not followng the bloating trend. Maybe the "not invented here" meme makes sense to some degree. What we as developers need is some understanding of what we're doing and not so much the latest bells and whistles. Storing data in a file may be unsophisticated, but it does the job even under hard conditions. ..but I am getting slightly off-topic ;-) Joachim > It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > Tim > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: >> >> Sean, >> >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. >> >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) >> >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. >> >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. >> >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. >> >> But, hey, I said all of that before. >> >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. >> >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? >> >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. >> >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. >> >> Joachim >> >> >> >> >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >>> jtuchel wrote >>>> Sigh. Forget about the idea that it will be easy to switch your >>>> persistence later....I am not commenting on SimplePersistence here, I >>>> don't even know what it >>>> does or doesn't. >>> Joachim, >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune >>> of a project growing enough to force me to make those tough choices! For >>> SimplePersistence I will say that I view it as a way to *delay* making *any* >>> choices until you are forced to. It's really just a layer of sugar on top of >>> Fuel (it used to use the old school Squeak equivalent serialization >>> mechanism - I forget the name and that might still work). You tell it what >>> classes to serialize. Implement two methods for each class that get and set >>> the data, and then it saves the whole thing as one object graph. >>> >>> Tim, >>> If you use SimplePersistence, please keep me posted about your experience. >>> I'm happy to help. >>> >>> NB I have maintained and extended the library, but it is the work of Ramon >>> Leon >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 7, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Pierce Ng

On Tue, Oct 06, 2020 at 09:41:21PM +0100, Tim Mackinnon wrote: > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ For Seaside, there is TF-Login. And oh, it rolled its own file-based versioning object persistence. Version that I ported to Pharo 7 and Seaside 3.3: - https://github.com/PierceNg/TF-Login/tree/pharo7 Feature branch for better security: - https://github.com/PierceNg/TF-Login/tree/password Some of the classes are too tightly coupled IMO. Also I'm tending towards an API-first approach, which needs OAuth2 and OpenID Connect, meaning either more pieces to integrate or totally not using this. Pierce

Oct. 7, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Offray Vladimir Luna CÃ¡rdenas

Hi, I have been using STON and Fossil for persistance and I'm pretty happy with this combination as a future proof, simple and even reproducible solution for my storage needs, including web hosting. For example, for our last project about IndieWeb with pocket infrastructures[1], a STON powered Grafoscopio[2] notebook[2a] describes the computations in Brea[3] that create the web site at [1], everything else are just plain markdown files with YAML metadata blocks[3a] and mustache templates[4] that combined create the HTML files. Maybe this combination is too "static web site" oriented, but now that you are looking for a panoramic view on persistence, could be helpful to put this in the radar. [1] https://mutabit.com/repos.fossil/indieweb/ [2] https://mutabit.com/grafoscopio/en.html [2a] https://mutabit.com/repos.fossil/indieweb/file?name=indieweb.ston&ci=trunk [3a] https://mutabit.com/repos.fossil/indieweb/tree?ci=trunk&type=tree&name=docs… [3] https://mutabit.com/repos.fossil/brea/ [4] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/pagina.mus.html All my projects are run in a 5 USD Digital Ocean instance. I have not need for anything else, as computing, when necessary, is distributed in the desktops of the users that install and run Grafoscopio and Brea. The server only synchronizes and stores files via Fossil repositories. Cheers, Offray On 6/10/20 3:41 p.Â m., Tim Mackinnon wrote: > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. > > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ however, move too soon and you get bogged down with the details and you lose site of an MVP. > > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). I suppose this is where the Rails scaffolding was/is? such a jumpstart, you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > Tim > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: >> >> Sean, >> >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. >> >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) >> >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. >> >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. >> >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. >> >> But, hey, I said all of that before. >> >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. >> >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? >> >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. >> >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. >> >> Joachim >> >> >> >> >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >>> jtuchel wrote >>>> Sigh. Forget about the idea that it will be easy to switch your >>>> persistence later....I am not commenting on SimplePersistence here, I >>>> don't even know what it >>>> does or doesn't. >>> Joachim, >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune >>> of a project growing enough to force me to make those tough choices! For >>> SimplePersistence I will say that I view it as a way to *delay* making *any* >>> choices until you are forced to. It's really just a layer of sugar on top of >>> Fuel (it used to use the old school Squeak equivalent serialization >>> mechanism - I forget the name and that might still work). You tell it what >>> classes to serialize. Implement two methods for each class that get and set >>> the data, and then it saves the whole thing as one object graph. >>> >>> Tim, >>> If you use SimplePersistence, please keep me posted about your experience. >>> I'm happy to help. >>> >>> NB I have maintained and extended the library, but it is the work of Ramon >>> Leon >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>

Oct. 7, 2020