August 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

by Herbert VojÄÃk

If you want expressive DSL for various assertions, Mocketry has one. I sort-of used to this approach from JS testing where mocha actually expects you will use your own assertion lib (eg. chai). Herby Tim Mackinnon wrote on 10. 8. 2018 16:34: > Actually - all those methods are already there - it looks like no-one > could decide, so I agree that it should be small and concise - however > equally test failures should be clear and easy to deal with - which is > where assert:equals: is brilliant - such a huge time saver when you hit > it, as you can easily understand the problem. So similarly, deny:equals: > is a big saver as well - you get the same immediate feedback that > confirms what happened in a test. > > If the interface is too thin - and you have to create all these helper > methods yourself - its just a pain. Â But it would be good to agree on > whether we are using assert or should. > > Tim > >> On 10 Aug 2018, at 16:16, Joachim Tuchel <jtuchel(a)objektfabrik.de >> <mailto:jtuchel@objektfabrik.de>> wrote: >> >> I personally think that the methods you suggest as examples pollute >> the API without adding any value. Just because Java and others added >> these doesnât justify a bad API. SUnit was intended to be mean and >> lightweight. Adding lots of permutations to it doesnât actually make >> it any better, just ugly. >> >> I see some space for improvements in logging and keeping details for >> CI scenarios, however. >> >> Joachim >> >> Am 10.08.2018 um 10:33 schrieb Guillermo Polito >> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >> >>> Personally I think that SUnit needs love. >>> Â - The API is clearly not clear (just see: the command line handler, >>> smalltalk ci, calypso and the test runner tool use different APIs >>> that are not equivalent and do not go through the same hooks) >>> Â - The existing hooks are not enough and not well documented, other >>> than overriding #runCase:, how can we define parameterizable tests >>> for example? >>> >>> With Julien (in cc) we were thinking some improvements on this front. >>> He has a new UI for the test runner that is cleaner and will allow >>> having different backends (which will mean also that we will need to >>> clarify the API). >>> >>> I think in Pharo7 there have been some improvements in the assertions >>> front? >>> >>> On Thu, Aug 9, 2018 at 3:07 PM Tim Mackinnon <tim(a)testit.works >>> <mailto:tim@testit.works>> wrote: >>> >>> Iâm trying to write more exercism tests and Iâm baffled why there >>> isnât the inverse equivalent of #assert:equals: which shows a >>> useful test response where you can easily see whatâs going on. >>> >>> #assert:equals: is very nice, showing you a diff browser - I kind >>> of expect the opposite to be there, but it all looks like a bit >>> of mess with assert vs should and deny vs shouldnât -did we >>> change tact somewhere over the years and not deprecate stuff? >>> >>> Tim >>> >>> >>> >>> -- >>> >>> Guille Polito >>> Research Engineer >>> >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> CRIStAL - UMR 9189 >>> French National Center for Scientific Research - _http://www.cnrs.fr >>> <http://www.cnrs.fr/>_ >>> >>> *Web:* _http://guillep.github.io_ <http://guillep.github.io/> >>> *Phone: *+33 06 52 70 66 13 >>> >

Aug. 10, 2018

Re: [Pharo-users] Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

by Tim Mackinnon

Actually - all those methods are already there - it looks like no-one could decide, so I agree that it should be small and concise - however equally test failures should be clear and easy to deal with - which is where assert:equals: is brilliant - such a huge time saver when you hit it, as you can easily understand the problem. So similarly, deny:equals: is a big saver as well - you get the same immediate feedback that confirms what happened in a test. If the interface is too thin - and you have to create all these helper methods yourself - its just a pain. But it would be good to agree on whether we are using assert or should. Tim > On 10 Aug 2018, at 16:16, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > > I personally think that the methods you suggest as examples pollute the API without adding any value. Just because Java and others added these doesnât justify a bad API. SUnit was intended to be mean and lightweight. Adding lots of permutations to it doesnât actually make it any better, just ugly. > > I see some space for improvements in logging and keeping details for CI scenarios, however. > > Joachim > > Am 10.08.2018 um 10:33 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > >> Personally I think that SUnit needs love. >> - The API is clearly not clear (just see: the command line handler, smalltalk ci, calypso and the test runner tool use different APIs that are not equivalent and do not go through the same hooks) >> - The existing hooks are not enough and not well documented, other than overriding #runCase:, how can we define parameterizable tests for example? >> >> With Julien (in cc) we were thinking some improvements on this front. He has a new UI for the test runner that is cleaner and will allow having different backends (which will mean also that we will need to clarify the API). >> >> I think in Pharo7 there have been some improvements in the assertions front? >> >> On Thu, Aug 9, 2018 at 3:07 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Iâm trying to write more exercism tests and Iâm baffled why there isnât the inverse equivalent of #assert:equals: which shows a useful test response where you can easily see whatâs going on. >> >> #assert:equals: is very nice, showing you a diff browser - I kind of expect the opposite to be there, but it all looks like a bit of mess with assert vs should and deny vs shouldnât -did we change tact somewhere over the years and not deprecate stuff? >> >> Tim >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13

Aug. 10, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Tim Mackinnon

Hey Marcus (or those knowledgable about stacks and contexts) - to self #1 - where the create button generates a class instead of a method, Iâm a bit out of my depth. I can see there is a DoesNotUnderstandDebugAction (which the create button calls). So to determine if the failure was due to a missing class or method - would this work? msg := self interruptedContext tempAt: 1. (msg lookupClass == UndefinedObject ) ifTrue: [ â¦ create a class E.g. if youâre trying to send a msg to nil (which is what got patched into the compiled method for a missing class) then you are dealing with a missing class? AND then for create a class - how do I extract the name? I can get the compiled method for msg - but how do I marry that up with what you were executing? Am I write in thinking that the AST nodes and there locations might line up with the stack pointer somehow (or something like that)â¦ if I can get that - then I get the name of the missing class and can then create it and then rerun the method right? This is very neat stuff I âve never played with before. Tim > On 9 Aug 2018, at 11:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 9 Aug 2018, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Hi Marcus, >> >> Is it wise to backport things that may break things like this? > maybe not, but it just took 5 minutes as it is very simple > >> I'd prefer to put the energy on backporting the workaround to avoid the infinite debuggers... >> > > Yes. > >> On Thu, Aug 9, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>>> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >>>> >>> >>> This is fixed in Pharo7: we added a menu entry âleave undeclaredâ as the first option: >>> <leave undeclared.png> >>>> Does anyone have tips on solving these? It spoils the exercism experience that I thought we could convey, so Iâd like to at least fix #1 in 6.1 if I can. >>>> >>> >>> I will back port the fix for 2) to Pharo6 and will do a quick prototype for 1) >>> >> >> https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U… <https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U…> >> >> Marcus >> >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 >

Aug. 10, 2018

Re: [Pharo-users] Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

by Joachim Tuchel

I personally think that the methods you suggest as examples pollute the API without adding any value. Just because Java and others added these doesnât justify a bad API. SUnit was intended to be mean and lightweight. Adding lots of permutations to it doesnât actually make it any better, just ugly. I see some space for improvements in logging and keeping details for CI scenarios, however. Joachim > Am 10.08.2018 um 10:33 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Personally I think that SUnit needs love. > - The API is clearly not clear (just see: the command line handler, smalltalk ci, calypso and the test runner tool use different APIs that are not equivalent and do not go through the same hooks) > - The existing hooks are not enough and not well documented, other than overriding #runCase:, how can we define parameterizable tests for example? > > With Julien (in cc) we were thinking some improvements on this front. He has a new UI for the test runner that is cleaner and will allow having different backends (which will mean also that we will need to clarify the API). > > I think in Pharo7 there have been some improvements in the assertions front? > >> On Thu, Aug 9, 2018 at 3:07 PM Tim Mackinnon <tim(a)testit.works> wrote: >> Iâm trying to write more exercism tests and Iâm baffled why there isnât the inverse equivalent of #assert:equals: which shows a useful test response where you can easily see whatâs going on. >> >> #assert:equals: is very nice, showing you a diff browser - I kind of expect the opposite to be there, but it all looks like a bit of mess with assert vs should and deny vs shouldnât -did we change tact somewhere over the years and not deprecate stuff? >> >> Tim > > > -- > > Guille Polito > Research Engineer > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Aug. 10, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Francisco Ortiz PeÃ±aloza

Marcus, I love this idea, not showing the menu at all would be more aligned to live coding. As you said in a later e-mail it must be fixed at runtime, while running the tests. Thanks! On Thu, Aug 9, 2018 at 5:07 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > >> 2) when coding - if you want reference a missing class, why donât we > let you? TonelReader seems to do it, why canât the editor? (This probably > applies to variables as well - show them broken, let me fix it when I > choose. The iVar case is a little rarer - although I hate the way we prompt > fix, prompt fix instead of doing it in one go - itâs very old fashioned) > >> > > > > > An alternative could be to not show the menu at all. Instead just compile > (I like the ideas that âeverything can be compiled and runâ). > > Just compile the Undeclared and instead of breaking the flow, we should > add a menu to the editor to do the âdefine Classâ âDefine Traitââ¦ > (with the gutter icons, we can provide a menu easily). > > I will make a small demo for that, too. > > Marcus >

Aug. 10, 2018

Re: [Pharo-users] Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

by Guillermo Polito

Personally I think that SUnit needs love. - The API is clearly not clear (just see: the command line handler, smalltalk ci, calypso and the test runner tool use different APIs that are not equivalent and do not go through the same hooks) - The existing hooks are not enough and not well documented, other than overriding #runCase:, how can we define parameterizable tests for example? With Julien (in cc) we were thinking some improvements on this front. He has a new UI for the test runner that is cleaner and will allow having different backends (which will mean also that we will need to clarify the API). I think in Pharo7 there have been some improvements in the assertions front? On Thu, Aug 9, 2018 at 3:07 PM Tim Mackinnon <tim(a)testit.works> wrote: > Iâm trying to write more exercism tests and Iâm baffled why there isnât > the inverse equivalent of #assert:equals: which shows a useful test > response where you can easily see whatâs going on. > > #assert:equals: is very nice, showing you a diff browser - I kind of > expect the opposite to be there, but it all looks like a bit of mess with > assert vs should and deny vs shouldnât -did we change tact somewhere over > the years and not deprecate stuff? > > Tim > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 10, 2018

Re: [Pharo-users] Dynabook concept under Dr. Geo perspective

by Hilaire

In the cited post bellow, I pointed to the wrong text regarding Dr. Geo and Dynamic media. Here is the right one: http://blog.drgeo.eu/post/2018/Dr.-Geo-and-Dynamic-media Hilaire Le 19/07/2018 Ã 15:19, Hilaire a Ã©critÂ : > Hi, > > The Dynabook concept and Dr. Geo share some values. > > Here is how http://blog.drgeo.eu/post/2018/The-Dynabook-Concept > > Hilaire -- Dr. Geo http://drgeo.eu

Aug. 10, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Guillermo Polito

On Thu, Aug 9, 2018 at 11:18 AM Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 08.08.2018 um 14:12 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: > > > > Damien Pollet wrote on 8. 8. 2018 13:53: > > First of all, quick stupid question: I'm currently loading my code with > gitlocal://./src as the repository URL (my workflow starts in a terminal > rather than in a Pharo image) > Should I just remove the /src part, now that my repo has the project > metadata? > Also, are more features planned for the .project file? E.g. what about > storing a default selection for Calypso and the Test Runner in there? > On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name < > mailto:norbert@hartl.name <norbert(a)hartl.name>>> wrote: > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this > however. I keep frontend and backend code in some repositories > together so the source is in my case in backend/source. What does it > mean for users not using the âstandardâ name? > Sure there can. Look at any ruby or maven project, they all have strong > conventions for organizing projects and standard config files for deviating > from those conventions. > I would have preferred if Iceberg picked one convention (arbitrarily) in > the absence of a .project file instead of forcing its explicit presence. > IMHO the choice of default directory per se (be it ./, ./src, ./source or > whatever) matters less than the fact that there is a convention in place. > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment > already but the .project file manifests this. So it should not be > supported to have more source dirs in one git repo? It might be not > a good idea that the client has to write the source dir but it opens > the possibility that there can be more than one. > I see your point here, but by using separate source directories you're > sort of creating a hydra projectâ¦ What I mean here is that the source > directories are separate, but their histories are tangled. If you want > separate source dirs it kinda means that you want separate change > histories, doesn't it? What if the same class has diverging definitions in > separate directories (I wonder what maven does in that caseâ¦)? > > > There are monorepos. Some people / companies love them. > > One of these companies we know for good. It is google. Google has one (!) > repositoryf for all their software. > > And that is the point I want to stretch here. One repo with one project > and a standard source directory is too theoretical and too narrow in > thoughts. > I think that you underestimate people when you say this. > Today there is no possibility to reliably make one product out of multiple > repos. Git submodule and git subtree are not even close to something > reliable and usable. > We are well aware of this. And that's why Pharo is not using any of them. But this goes against what you said before, or I'm not getting something. > Descriptions like metacello are language centric. > Yes. But I don't understand why this comes up. You would like language... "agnostic"? For example? > So what is the most secure way of defining a single product? It is the > mono repo. That is the main reason I have my sources in backend/source > because there is a javascript frontend in the same repo because I want to > have one reliable source that defines my product and I can be sure that the > backend and frontend are always the ones that match. > Just to repeat myself (and just to avoid missing it in the previous emails ^^). Can you describe better your needs for "multiple iceberg subdirectories"? > I donât think it is a good idea if we once leave the island to embrace > something like git just to make git islandish a little later. > I did not understand this... > > Just to be very clear. We are talking about two files: .project and > .properties. I have nothing against .properties because we have multiple > formats possible so making it explicit is a good idea. But .project makes > every repo a single source repo. If we enforce .properties files why do we > not scan the repo for directories containing this file? If none is found we > cannot know (or we add looking at some default locations). If multiple > directory are found I can add that to iceberg as a real project out of the > combination for repository-source directory. > This way I could have multiple projects out of one repo. And with the > possibility of having multiple source directories it is obvious that the > path still needs to be added to a url in metacello. > Unless there is one of this directories marked to be the default which > would be loaded if no directory is given. This way the default directory > would be the one selected if only one is there. So you can have multiple > projects in one repo and if this is only one per project the directory can > be automatically resolved. Use case kept. > Yes it could be done, but it's not so easy. I think you're underestimating the problem. For example, - tons of old projects have no .properties file. - so far iceberg only explicitly supported one code directory, and assumed that "no subdirectory" means root directory, not "default" one - If we discover two subdirectories in your repository, and you add a package into your repository, in which subdirectory should it be? - Should in this case be able to add the same package to both subdirectories? Do we commit them at the same time? Or they have different versions? Let's add that all these changes may involve changes in: - UI (and doing it properly takes time to design it, not just "coding" it) - merge Now, again, I can understand that the change make you uncomfortable, but I'd prefer that we talk about what are your needs instead of "how easy it could be done if we weren't stupid". > > Norbert > > On the other hand, separate source directories would be helpful to work > with git-subrepo and similar toolsâ¦ > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 9, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Guillermo Polito

> > [SNIP] > I think I can see what is the rationale behind it but Iâm not sure this > can be the way to go: > > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this however. I > keep frontend and backend code in some repositories together so the source > is in my case in backend/source. What does it mean for users not using the > âstandardâ name? > Well, I think the opposite. The tool should enforce some standard way, and then, if you want to diverge from it you should specify it explicitly. > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment already > but the .project file manifests this. So it should not be supported to have > more source dirs in one git repo? It might be not a good idea that the > client has to write the source dir but it opens the possibility that there > can be more than one. > Our solution doesn't close the door either. Actually, we were thinking on having composite projects (a project with subprojects), which would support your use case. We are aware we wanted this for Pharo so for example we can split pharo itself in several smaller subprojects instead of having the mess of ~500 packages we have today. However, we were not aware of any project out there using such setup, and previous iceberg versions was maybe supporting this just "by chance" and not by design. (Just imagine that having in the same image two repositories with the same git repository behind but different source directories could be a way, but it's more of a workaround). This said, could you explain better how you were using this so far? - you have different source directories for frontend/backend? - you interact with them as different repositories in the same image? or from different images pointing to the same repo? - every time you commit in one of the iceberg repositories you get detached in the other(s)? This said, I'd like to support this scenarios, but I want to do it by design :) > - My mode of working is to have an eye on dirty repositories because that > shows what the impact of your work is. If I have a lot of dirty > repositories in my repository list it does not feel good and I donât want > that. Especially for projects I donât have write access to. How can I > change this? Iâm not sure that assuming everyone will add these files is a > likely one. > Maybe we need to be less invasive with colors? My point of view is that Monticello shows tons of packages and repositories, automatic rewrite and auto-deprecation rules rewrite code dynamically and mark monticello packages as dirty. But nobody ever complained about monticello or tried to change it. What are the packages you depend on and you have no write access to? If we make a pull request per day, I think we can solve this situation really fast... > > Norbert > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 9, 2018

Dynabook and group learning

by Hilaire

Some though on Dynabook and learning in group. http://blog.drgeo.eu/post/2018/Learning-in-group -- Dr. Geo http://drgeo.eu

Aug. 9, 2018