June 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Mm10s] 2020-06-08

by tesonep＠gmail.com

### Last week: - Monday Holiday - Multiple images test runners - [VM] Writing tests for JIT generation - Idle VM with Esteban: Gtk - Missing parts in the Image to have Sista + FullBlockClosure. - Reviewing PR & Issues ### This week (starting 2020-06-08): - Releasing VM with LibGit 1.0.0 - Multiple images test runners - [VM] Writing tests for JIT generation - Idle VM with Esteban: Gtk On Mon, Jun 8, 2020 at 10:03 AM Esteban Lorenzano <estebanlm(a)netc.eu> wrote: > > > ### Last week: > > > * [Idle-VM] w/Pablo. Worker problem with delays > worker version was not interrupting the aio. We spent some time here and this was a non existing > problem at the end (but we found and fix a bug on Spec2-Gtk). > * [Idle-VM] problem when save&quit image with gtk backend > fix a bug happening when application was shutting down and some events want still happen, who > causes a callback that is alredy discarded to be executed. > * [Idle-VM] new version of memory access > test, bench and merge of new memory access primitive > (lowcode didn't applied, finally) > * [spec2] preparation of a window box to make some tests there. > * [spec2] gtk backend now has an image-side based tree store, which allows much better > interoperability. Next task is to migrate the adaptors: list, table and treetable (not trivial, > but needed) > * [TFFI] added a new type: FFIBoolean32 to handle the fact that many libraries (in my case, > Gtk), do not use bool=8bit implementation. Now, users need to map their boolean (in my case, > gboolean) to this type by hand. I didn't find a better way to fix this issue :( > * [spec2] gtk backend now answers propertly to keyboard events in windows. > * [spec2] fix a (new) bug on GtkTreeView, because we do not need to unref stores manually. This > bug was introduced by my recent fix on GtkTreeView, which initialize method was not sending > super. > * [spec2] avoid the traverse of roots when releasing a GtkTreeDataStore (Gtk does that) > * [spec2] list/table/tree migrated to use the new GtkTreeDataStore (lots of simplifications, > specially on GtkTreeTableAdapter) > * [NewTools-Playground] bug: doit from toolbar does not uses interactionMode > * [Spec2-doc] Add style section (reference) to SpApplication > * [NewTools-Playground] bug: "implementors" is not working. I couldnât reproduce the problem. > Maybe is fixed now? > > ### This week (starting 2020-06-08): > > > - Mostly cleanups and re-organisations on Spec2 (preparing v0.7 for Pharo9) > - Preparing v0.1 of NewTools (also, to prepare an integration to Pharo9) > - Building VM on Fedora linux > - Testing Idle-VM on Windows > > > -- Pablo Tesone. tesonep(a)gmail.com

June 8, 2020

Re: [Pharo-dev] [Cuis-dev] PROPOSAL: UN-St (United Nations of Smalltalk)

by Jonathan van Alteren

Hi Sean, I just wanted to say that I share your vision about the need to unleash the true power of computing and evolving humanity (not just the mind, I hope). The Smalltalk community, in all its rich diversity, has so much potential. It deserves to grow and be united in collaboration, which I think could be helped by your proposal. I'm still very much a junior in Pharo and Smalltalk in general, and my time is very limited. I think others will be far better suited to support your initiative. However, you're welcome to send me a PM if you think I can help, it's always good to talk. Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations jvalteren(a)objectguild.com On 4 Jun 2020, 18:17 +0200, Sean DeNigris via Cuis-dev <cuis-dev(a)cuis-smalltalk.org>, wrote: > I believe that the Squeak/Pharo/Cuis communit(ies) share one very special thing, which most of the world has completely missed, and which the world sorely needs if the true power of computing to unleash and evolve the human mind is ever to be realized: a love and appreciation for personal technological augmentation/amplification available to all as represented by the Dynabook and/or its prototype software (Smalltalk as a concept, not any version/implementation e.g. Smalltalk-80). > > Like a few survivors after the sinking of Atlantis, we can pick up the remnants of this dream and resume marching toward the objective (or at least keep its memory alive until an auspicious time when it can be realized)â¦ or, like most groups of human beings throughout history who start with a common aim, we can bicker among ourselves about e.g. historical discrepancies, personal slights, and conflicting subgoals, and allow those squabbles to distract us and derail our primary mission. This would be disappointing but not surprising: it is how every war is started. > > I have contributed, hacked, conferenced, and visited with many members of our wider community for over a decade now and, maybe because I had the âluxuryâ of finding Smalltalk after some of the political lines had been well-drawn, I can clearly see that we are fundamentally united. I cringe every time I see cynical, caustic exchanges - both for my participating colleagues who are obviously in pain - probably exacerbated by their passion for our shared endevour - and for the counterproductive effect the antagonism is sure to have on our common goal. Virtually every exchange is between two people who I personally know to be good and competent. > > Here is my proposal: Letâs form an informal committee - a United Nations of Smalltalk if you will - including at least one member of each community, who will collaborate on cooperation between the dialects and mediate any friction before it boils over. > > Iâd be happy to participate, I guess as a representative of the Pharo community. Although I have no official role in the Pharo leadership, I have much of my professional life invested there. I often wish I had the time to keep all my projects compatible with Squeak, but I usually feel like Iâm barely keeping up as it is! > > I hope Iâm not alone in these feelings and look forward to the response of our community (most emphatically singular). This message is being cross-posted to Pharo-Dev, Squeak-Dev, and Cuis MLs (I think Iâm still a member of all three - fingers crossedâ¦) > > - Sean (DeNigris) > _______________________________________________ > Cuis-dev mailing list > Cuis-dev(a)cuis-smalltalk.org > http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org

June 8, 2020

[Mm10s] 2020-06-08

by Esteban Lorenzano

### Last week: * [Idle-VM] w/Pablo. Worker problem with delays worker version was not interrupting the aio. We spent some time here and this was a non existing problem at the end (but we found and fix a bug on Spec2-Gtk). * [Idle-VM] problem when save&quit image with gtk backend fix a bug happening when application was shutting down and some events want still happen, who causes a callback that is alredy discarded to be executed. * [Idle-VM] new version of memory access test, bench and merge of new memory access primitive (lowcode didn't applied, finally) * [spec2] preparation of a window box to make some tests there. * [spec2] gtk backend now has an image-side based tree store, which allows much better interoperability. Next task is to migrate the adaptors: list, table and treetable (not trivial, but needed) * [TFFI] added a new type: FFIBoolean32 to handle the fact that many libraries (in my case, Gtk), do not use bool=8bit implementation. Now, users need to map their boolean (in my case, gboolean) to this type by hand. I didn't find a better way to fix this issue :( * [spec2] gtk backend now answers propertly to keyboard events in windows. * [spec2] fix a (new) bug on GtkTreeView, because we do not need to unref stores manually. This bug was introduced by my recent fix on GtkTreeView, which initialize method was not sending super. * [spec2] avoid the traverse of roots when releasing a GtkTreeDataStore (Gtk does that) * [spec2] list/table/tree migrated to use the new GtkTreeDataStore (lots of simplifications, specially on GtkTreeTableAdapter) * [NewTools-Playground] bug: doit from toolbar does not uses interactionMode * [Spec2-doc] Add style section (reference) to SpApplication * [NewTools-Playground] bug: "implementors" is not working. I couldnât reproduce the problem. Maybe is fixed now? ### This week (starting 2020-06-08): - Mostly cleanups and re-organisations on Spec2 (preparing v0.7 for Pharo9) - Preparing v0.1 of NewTools (also, to prepare an integration to Pharo9) - Building VM on Fedora linux - Testing Idle-VM on Windows

June 8, 2020

[Pharo 9.0] Build #342: [Flaky Test] Rely on SUnit time limit in recursion stopper tests.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #342 was: FAILURE. The Pull Request #6501 was integrated: "[Flaky Test] Rely on SUnit time limit in recursion stopper tests. " Pull request url: https://github.com/pharo-project/pharo/pull/6501 Issue Url: https://github.com/pharo-project/pharo/issues/recursionStopperTests Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 8, 2020

[Pharo 9.0] Build #341: 6495-Better-class-API

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #341 was: FAILURE. The Pull Request #6502 was integrated: "6495-Better-class-API" Pull request url: https://github.com/pharo-project/pharo/pull/6502 Issue Url: https://github.com/pharo-project/pharo/issues/6495 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 7, 2020

What to do with our failing CI?

by Denis Kudriashov

Hello. We have a failing CI for quite a long time (maybe few months). And out of that there are always new flaky tests failing our PRs time to time. We did fix some of them but I do not think it is possible to avoid them at all. I propose a simple approach/convention to quickly recover CI from such appearing intermittent problems. When we detect a flaky test let's do two simple PRs: 1. [Disable Flaky Test] PR will skip problem tests and flag them to be easily found in the image. testWithIntermitentIssue self flag: #flakyTest self skip. "the rest of test code" This PR is supposed to be quickly merged to avoid failures in new PRs 2. [Enable Flaky Test] PR will enable tests back. It will record the issue and track the current "flaky state". For example I created two PRs for Zinc tests: - [Disable Flaky Tests] Disable two Zinc flaky tests <https://github.com/pharo-project/pharo/pull/6497> - [Enable Flaky Tests] Enable two Zinc flaky tests <https://github.com/pharo-project/pharo/pull/6498> The enable PR here will be always red until we integrate a fix. Of course some issues are trivial to fix like increasing the allowed time for the test. And we should just push the fix. But when it is not clear what to do it is better to remove the case from the overall CI and localize the issue in concrete PR. So expert devs could look at the problem without interrupting the contribution of other people. I think it's a very easy approach to follow by anyone. And it can be even automated. That's my idea. Best regards, Denis

June 7, 2020

Re: [Pharo-dev] Discoverability

by Denis Kudriashov

Hi Sean. Ð¿Ñ, 5 Ð¸ÑÐ½. 2020 Ð³. Ð² 21:16, Sean P. DeNigris <sean(a)clipperadams.com>: > BTW am I alone in thinking that the class list should be treated as a tree > by default? It basically is a tree *already*, but without the ability to > collapse/expand which limits understanding a large tree where siblings may > be far apart when it's fully expanded. > I think collapsing buttons add "extra icons noise". I also thought to enable it by default but I did not like how it visually looks. Maybe I just need to get used to it. I will comment your PR. It requires more work I think

June 6, 2020

Re: [Pharo-dev] [Pharo-users] json-server / db.json (lowdb) / faker.js in Pharo/Zinc ?

by CÃ©drick BÃ©ler

Hi, > > Hi CÃ©drick, > > I think making something like jsonplaceholder would be quite easy. > > Do you know about the Zinc-REST package/group ? I knew but forget about it ! > > It contains an example in its tests, ZnExampleStorageRestServerDelegate with unit tests in ZnExampleStorageRestServerDelegateTest which implements a generic data storage. Have a look ! Will definitely look again at it. Is it using a json file as db too ? I guess that be easy to add if not. Iâll look at it soon. Any feedback about faker ? Thatâd be a fun project to do in Pharo. There are lots of them. I donât know which one to look at more in detail (js, ruby, python, php... ?). https://github.com/faker-ruby/faker https://github.com/marak/Faker.js/ https://github.com/joke2k/faker â¦ Anybody knows whatâs the most Â« complete Â» or elegant ? > > BTW, recently I added ZnClient>>#forJsonREST, which uses either STONJSON (which is in the image) or NeoJSON (when loaded), so that you can more elegant code for this use case: Uhm right, I always forget and use the old way (with #contentReader: ). Thanks for the information Sven, CÃ©drick > > ZnClient new > url: 'https://jsonplaceholder.typicode.com/posts'; > forJsonREST; > get. > > ZnClient new > url: 'https://jsonplaceholder.typicode.com/posts'; > forJsonREST; > contents: { #title->'Test'. #body->String loremIpsum } asDictionary; > post. > > Sven > >> On 6 Jun 2020, at 09:44, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> >> Hi Sven and all, >> >> Disclaimer: just another rather not important query (mainly for fun so donât hesitate to tell me to use the node packages instead ;-) ) >> >> To show API to students, I sometimes use https://jsonplaceholder.typicode.com. Itâs nice to play with client requests. I wonder if this would be interesting to have such tools in Pharo/Zn. Maybe it exists already somehow (for Teapot eventually) ? >> https://medium.com/codingthesmartway-com-blog/create-a-rest-api-with-json-s… >> >> From their GitHub, I discovered json-server + lowdb (based on lowdash) => all nodes packages. >> https://github.com/typicode. >> >> <GraphiqueCollÃ©-6.tiff> >> >> It uses a db file db.json and I like such simple Â« databases Â». I know they're not real db. >> https://github.com/typicode/lowdb >> >> To me, it could nearly be to me an elegant personal db even if I think this is mostly used to test APIâs. >> Indeed, Itâs often used in conjunction with node package faker (https://github.com/marak/Faker.js/ (https://github.com/marak/Faker.js/) >> I would like to use that to generate static websites from Ecstatic. >> >> The placeholder default website has limitations. For instance, the following request creates a new post (but then you cannot see the result if you query for posts just after) >> >> <GraphiqueColleÌ-5.png> >> >> >> I wanted to go past the limitation of the placeholder site (the db.json cannot be written). I can of course use the node package but you know :) Might be not so straight to port though. >> >> So there are probably three open questions in this post: >> 1) lowdb (I know this is not a database but itâs handy and Iâd like such usage in static website generation in conjunction with Ecstatic). Any already existing experiments maybe ? I donât think Voyage can do that. >> 2) the API json-server based on routes (maybe a job for Teapot) ? >> 3) the faker package as a fun exercice. >> >> What others think ? My priority would go for having some kind of lowdb (and Iâm pretty sure there are experiments around that - It reminds me a bit sandstonedb from Ramon http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in…. >> >> Cheers, >> >> CÃ©drick >> >> >> > >

June 6, 2020

Re: [Pharo-dev] json-server / db.json (lowdb) / faker.js in Pharo/Zinc ?

by Sven Van Caekenberghe

Hi CÃ©drick, I think making something like jsonplaceholder would be quite easy. Do you know about the Zinc-REST package/group ? It contains an example in its tests, ZnExampleStorageRestServerDelegate with unit tests in ZnExampleStorageRestServerDelegateTest which implements a generic data storage. Have a look ! BTW, recently I added ZnClient>>#forJsonREST, which uses either STONJSON (which is in the image) or NeoJSON (when loaded), so that you can more elegant code for this use case: ZnClient new url: 'https://jsonplaceholder.typicode.com/posts'; forJsonREST; get. ZnClient new url: 'https://jsonplaceholder.typicode.com/posts'; forJsonREST; contents: { #title->'Test'. #body->String loremIpsum } asDictionary; post. Sven > On 6 Jun 2020, at 09:44, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Hi Sven and all, > > Disclaimer: just another rather not important query (mainly for fun so donât hesitate to tell me to use the node packages instead ;-) ) > > To show API to students, I sometimes use https://jsonplaceholder.typicode.com. Itâs nice to play with client requests. I wonder if this would be interesting to have such tools in Pharo/Zn. Maybe it exists already somehow (for Teapot eventually) ? > https://medium.com/codingthesmartway-com-blog/create-a-rest-api-with-json-s… > > From their GitHub, I discovered json-server + lowdb (based on lowdash) => all nodes packages. > https://github.com/typicode. > > <GraphiqueCollÃ©-6.tiff> > > It uses a db file db.json and I like such simple Â« databases Â». I know they're not real db. > https://github.com/typicode/lowdb > > To me, it could nearly be to me an elegant personal db even if I think this is mostly used to test APIâs. > Indeed, Itâs often used in conjunction with node package faker (https://github.com/marak/Faker.js/ (https://github.com/marak/Faker.js/) > I would like to use that to generate static websites from Ecstatic. > > The placeholder default website has limitations. For instance, the following request creates a new post (but then you cannot see the result if you query for posts just after) > > <GraphiqueColleÌ-5.png> > > > I wanted to go past the limitation of the placeholder site (the db.json cannot be written). I can of course use the node package but you know :) Might be not so straight to port though. > > So there are probably three open questions in this post: > 1) lowdb (I know this is not a database but itâs handy and Iâd like such usage in static website generation in conjunction with Ecstatic). Any already existing experiments maybe ? I donât think Voyage can do that. > 2) the API json-server based on routes (maybe a job for Teapot) ? > 3) the faker package as a fun exercice. > > What others think ? My priority would go for having some kind of lowdb (and Iâm pretty sure there are experiments around that - It reminds me a bit sandstonedb from Ramon http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in…. > > Cheers, > > CÃ©drick > > >

June 6, 2020

json-server / db.json (lowdb) / faker.js in Pharo/Zinc ?

by CÃ©drick BÃ©ler

Hi Sven and all, Disclaimer: just another rather not important query (mainly for fun so donât hesitate to tell me to use the node packages instead ;-) ) To show API to students, I sometimes use https://jsonplaceholder.typicode.com. Itâs nice to play with client requests. I wonder if this would be interesting to have such tools in Pharo/Zn. Maybe it exists already somehow (for Teapot eventually) ? https://medium.com/codingthesmartway-com-blog/create-a-rest-api-with-json-s… >From their GitHub, I discovered json-server + lowdb (based on lowdash) => all nodes packages. https://github.com/typicode. It uses a db file db.json and I like such simple Â« databases Â». I know they're not real db. https://github.com/typicode/lowdb To me, it could nearly be to me an elegant personal db even if I think this is mostly used to test APIâs. Indeed, Itâs often used in conjunction with node package faker (https://github.com/marak/Faker.js/ (https://github.com/marak/Faker.js/) I would like to use that to generate static websites from Ecstatic. The placeholder default website has limitations. For instance, the following request creates a new post (but then you cannot see the result if you query for posts just after) I wanted to go past the limitation of the placeholder site (the db.json cannot be written). I can of course use the node package but you know :) Might be not so straight to port though. So there are probably three open questions in this post: 1) lowdb (I know this is not a database but itâs handy and Iâd like such usage in static website generation in conjunction with Ecstatic). Any already existing experiments maybe ? I donât think Voyage can do that. 2) the API json-server based on routes (maybe a job for Teapot) ? 3) the faker package as a fun exercice. What others think ? My priority would go for having some kind of lowdb (and Iâm pretty sure there are experiments around that - It reminds me a bit sandstonedb from Ramon http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in…. Cheers, CÃ©drick

June 6, 2020