- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] OpenSSL binding Re: About strange email related to smalltalkhub read-only on squeak-dev

by Pierce Ng

On Thu, Jun 04, 2020 at 10:31:09AM +0200, Norbert Hartl wrote: > > Am 04.06.2020 um 02:44 schrieb Pierce Ng <pierce(a)samadhiweb.com>: > > On Tue, Jun 02, 2020 at 11:17:30AM +0200, Norbert Hartl wrote: > >> PierceNg has an implementation that implements a subset of openssl. > >> This implementation is modeled after the library so lots of class > >> methods. I'd prefer to have something more object model like. > > > > A very small subset currently, as my original need was to create an X509 > > request in code. PRs welcome. > > > > https://github.com/PierceNg/OpenSSL-Pharo > > > If it is a small subset it might be feasible to talk about the approach taken. Sure. I don't see too many misplaced class methods myself. I've just loaded the package into a fresh image for a spin. My self-built VM uses OpenSSL 1.1.1 (instead of OpenSSL 1.0.x in the prebuilt VMs) and there are C API changes between those two OpenSSL versions that break many tests, basic things like XXX_create becoming XXX_new, XXX_init becoming XXX_reset etc. So I've created branches openssl_1_1 and openssl_1_0 that will match the versions used by Pharo. Pierce

June 6, 2020

Re: [Pharo-dev] Discoverability

by Sean P. DeNigris

Sean P. DeNigris wrote > Fixed https://github.com/pharo-project/pharo/pull/6493 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 5, 2020

Re: [Pharo-dev] Discoverability

by Sean P. DeNigris

Sean P. DeNigris wrote > the icons and arrows themselves are not properly indented (they are all in > one vertical > line regardless of depth in tree) :/ Fixed: `displayMainColumnBy: [ :cell :item | cell useFullIndentation... ]` ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 5, 2020

Re: [Pharo-dev] Discoverability

by Sean P. DeNigris

Denis Kudriashov wrote > Try to replace... with... Thanks!! That added tree node arrows to the class tree :) but the icons and arrows themselves are not properly indented (they are all in one vertical line regardless of depth in tree) :/ 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. Also, I can't imagine ever coming up with all that on my own, so I'm glad I asked, but I'm worried about the future extensibility/maintenance if original authors aren't available :/ Denis Kudriashov wrote > You were in the right direction. But there is a little detail here. > By default your code would work for domain objects in the list (not a > class > view). > But the problem with classes and methods lists is to support the Ring > model > where classes are not instances of Class and methods are not instances of > CompiledMethod. > My solution was to have a data type for query items. By default it is an > actual class of objects. But for classes and methods I introduced > ClyClass and ClyMethod to address the Ring case. > > So try following in your experiment > ClyClass -> #prepareProjectItemsQueryFrom:in: > And you should have a debugger. > > I wonder, did you try a halt in #treeStructure users . I think it would > help to discover this logic. I checked for senders of #treeStructure (there were none) and then references to the underlying inst var, but for some reason my eyes glossed over `queryToExpand:ifAbsent:` and I only ran across it much later in a debugger, but I don't remember from what route. Although, given your solution above, is this even necessary? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 5, 2020