- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Development process: testing the GUI

by Esteban Lorenzano

Hi, Wellâ¦ we âplanâ to have tests also on UI. But this is hard. And not just because of the tooling, but also because having a coherent metaphor to organise everything is hard. We are working (very slowly) in that direction. And eventually, we would like to have also UI tests. Esteban > On 12 Jan 2019, at 23:34, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi all, > Pharo team is attaching great care in securing and improving the development process, notably by promoting usage of tests and continuous integration. > > I think a very good job is already done in the libraries provided by Pharo. But sometimes I encounter more hickups with the development tools themselves. > So I wonder: does this apply to the GUI yet? > This is a difficult area, but nowadays this exists elsewhere. > For example, with Elm and Elmer (https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8 <https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8>), TDD can be applied on UI, providing both a formal specification and non regression tests. > Do we have something similar? > Don't we wish having something similar?

Jan. 13, 2019

Development process: testing the GUI

by Nicolas Cellier

Hi all, Pharo team is attaching great care in securing and improving the development process, notably by promoting usage of tests and continuous integration. I think a very good job is already done in the libraries provided by Pharo. But sometimes I encounter more hickups with the development tools themselves. So I wonder: does this apply to the GUI yet? This is a difficult area, but nowadays this exists elsewhere. For example, with Elm and Elmer ( https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8) TDD can be applied on UI, providing both a formal specification and non regression tests. Do we have something similar? Don't we wish having something similar?

Jan. 12, 2019

Re: [Pharo-dev] IceGitHubError API rate limit exceeded

by Paul DeBruicker

github allows 60 unauthenticated requests per hour per IP. IF you authenticate your requests you can make 5,000 per hour. If you don't want to wait an hour after hitting this error you should create a personal, no scope token following the instructions here: https://blog.github.com/2013-05-16-personal-api-tokens/ The no-scope token can only be used to read public repository information and cannot make any changes to any of your repos. You can use the token to authenticate your requests by setting your github username as the username and the token as the password in a HTTP basic authentication request to their servers. I know ZnClient has #username:password: and so guess that Iceberg has or can have a similar method. Dont share the token. bpi wrote > Hi, > > I followed these instructions for contributing to Pharo: > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > During Step 1 Repairing local repository missing I get the following > error: > IceGitHubError: API rate limit exceeded > > I retried with a new Pharo 7.0 - 64bit (development version) in Pharo > Launcher and got the same error. > > I searched the mailing list but did not find anything. Am I really the > only one who ever encountered this? Any tips? > > Cheers, > Bernhard -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 12, 2019

Re: [Pharo-dev] IceGitHubError API rate limit exceeded

by Sabine Manaa

Hi Bernhard, I did not go deep in it but this could be related or similar: -> https://github.com/pharo-vcs/iceberg#for-pharo-61 -> If you get a API rate limit exceeded error from github, like "Error accessing tags for github project: 'pharo-vcs/iceberg' -> 'API rate limit exceeded for...." then you can replace the metacello statement above with: Metacello new githubUser: 'pharo-vcs' project: 'Iceberg' commitish: 'v1.?' path: ''; baseline: 'Iceberg'; load. -> https://developer.github.com/v3/#rate-limiting regards Sabine Am Sa., 12. Jan. 2019 um 19:52 Uhr schrieb Bernhard Pieber < bernhard(a)pieber.com>: > > Hi, > > I followed these instructions for contributing to Pharo: > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > During Step 1 Repairing local repository missing I get the following error: > IceGitHubError: API rate limit exceeded > > I retried with a new Pharo 7.0 - 64bit (development version) in Pharo Launcher and got the same error. > > I searched the mailing list but did not find anything. Am I really the only one who ever encountered this? Any tips? > > Cheers, > Bernhard

Jan. 12, 2019

IceGitHubError API rate limit exceeded

by Bernhard Pieber

Hi, I followed these instructions for contributing to Pharo: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo During Step 1 Repairing local repository missing I get the following error: IceGitHubError: API rate limit exceeded I retried with a new Pharo 7.0 - 64bit (development version) in Pharo Launcher and got the same error. I searched the mailing list but did not find anything. Am I really the only one who ever encountered this? Any tips? Cheers, Bernhard

Jan. 12, 2019

Re: [Pharo-dev] Availability of Smallapack in Pharo6.0

by Denis Kudriashov

Hi Nicolas Ð¿Ñ, 11 ÑÐ½Ð². 2019 Ð³. Ð² 23:34, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi, > I announce the availability of Smallapack in Pharo6. > > The ConfigurationOfSmallapack is in > http://www.squeaksource.com/MetacelloRepository and there is a copy in > meta repo for Pharo 3/4/5/6. > > Currently, the ported version uses a derivative of OpalCompiler patched to > handle method with 16+ arguments. > External function calls have not been converted yet to UnifiedFFI, but the > patched compiler rather has hook to compile legacy FFI. > Though I did not install the hook to call FFI with more than 15 arguments, > so there is at least 1 unit test failing (but not crashing). > > I have auto-re-generated all the source code for using UnifiedFFI formats, > so the dependency on legacy FFI is not a necessity (apart for simplifying > cross dialect maintenance). > > But I want to review the generated code method by method rather than > filing it in blindly (the wrapper functions are also generated, and I might > loose comments or improvments if I'm careless). Unfortunately, the state of > diff tools in Pharo6, be it thru MC or worse than all, thru legacy change > lists, does not enable such a large scale review, so I think that I will > edit in Squeak and run in Pharo... > > Now that Smallapack supports Opal, there should be no major problem for > porting to Pharo7, but I did not have time to try yet. A few more MC > regressions, and the fact to forbid protocol beginning with a * was too > serious a cross compatibility hurdle for me. > Protocol with star is still convention to store class extensions in files. No compatibility issues here. Calypso just hides it from user because package and protocol is not the same thing. And I hope in Pharo 8 we will support multiple protocols and separate packaging. But more important is to finely clean RPackage implementation. The current way how method is became bound to package is horrible. > But I'll come back to it, tools are generally better in ph7 than ph6. Stay > tuned. > >

Jan. 12, 2019

Re: [Pharo-dev] DebugSession>>activePC:

by Denis Kudriashov

Hi guys. Funny thing that DebugSession does not exists in Squeak. It was introduced in Pharo to represent the model for debugger. Ð¿Ñ, 11 ÑÐ½Ð². 2019 Ð³. Ð² 22:34, Thomas Dupriez via Pharo-dev < pharo-dev(a)lists.pharo.org>: > Yeah, it's a bit unfortunate you assumed I wanted to remove the method. > It brought up a not so pleasant discussion. > Everyone makes mistakes. :-) > > So if I understand, this method gives the pc that maps to the ast node > the debugger should highlight when a context is selected in the stack > widget? If I'm right, how comes that this method has no senders in the > debugger code? That would mean this feature is also implemented > somewhere else. > > Thomas > > Le 11/01/2019 Ã 20:28, Eliot Miranda a Ã©crit : > > Hi Thomas, > > > > forgive me, my first response was too terse. Having thought about it > in the shower it becomes clear :-) > > > >> On Jan 11, 2019, at 6:49 AM, Thomas Dupriez < > tdupriez(a)ens-paris-saclay.fr> wrote: > >> > >> Hi, > >> > >> Yes, my question was just of the form: "Hey there's this method in > DebugSession. What is it doing? What's the intention behind it? Does > someone know?". There was no hidden agenda behind it. > >> > >> @Eliot > >> > >> After taking another look at this method, there's something I don't > understand: > >> > >> activePC: aContext > >> ^ (self isLatestContext: aContext) > >> ifTrue: [ interruptedContext pc ] > >> ifFalse: [ self previousPC: aContext ] > >> > >> isLatestContext: checks whether its argument is the suspended context > (the context at the top of the stack of the interrupted process). And if > that's true, activePC: returns the pc of **interruptedContext**, not of the > suspended context. These two contexts are different when the debugger opens > on an exception, so this method is potentially returning a pc for another > context than its argument... > >> > >> Another question I have to improve the comment for this method is: > what's the high-level meaning of this concept of "activePC". You gave the > formal definition, but what's the point of defining this so to speak? What > makes this concept interesting enough to warrant defining it and giving it > a name? > > There are two âmodesâ where a pc us mapped to a source range. One is > when stepping a context in the debugger (the context is on top and is > actively executing bytecodes). Here the debugger stops immediately before > a send or assignment or return, so that for sends we can do into or over, > or for assignments or returns check stack top to see what will be assigned > or returned. In this mode we want the pc of the send, assign or return to > map to the source range for the send, or the expression being assigned or > returned. Since this is the âcommon caseâ, and since this is the only > choice that makes sense for assignments ta and returns, the bytecode > compiler constructs itâs pc to source range map in terms of the pc of the > first byte if the send, assign or return bytecode. > > > > The second âmodeâ is when selecting a context below the top context. > The pc for any context below the top context will be the return pc for a > send, because the send has already happened. The compiler could choose to > map this pc to the send, but it would not match what works for the common > case. Another choice would appear be to have two map entries, one for the > send and one for the return pc, both mapping to the source range. But this > wouldnât work because the result of a send might be assigned or returned > and so there is a potential conflict. I stead the reasonable solution is > to select the previous pc for contexts below the top of context, which will > be the pc for the start of the send bytecode. > > > > HTH > > > >> Cheers, > >> Thomas > >> > >>> On 11/01/2019 13:53, Tudor Girba wrote: > >>> Hi, > >>> > >>> @Eliot: Thanks for the clarifying answer. > >>> > >>> I believe you might have jumped to conclusion about the intention of > the question. Thomas asked a legitimate question. Without users of a method > it is hard to understand its use. It does not necessarily imply that the > intention is to remove it, but it does show that someone wants to > understand. > >>> > >>> As far as I know, Thomas actually wants to write a test to cover that > usage. I am sure that you appreciate and encourage that :). > >>> > >>> @Thomas: Thanks for this effort! > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>>> On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >>>> > >>>> Hi Thomas, > >>>> > >>>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > >>>>> > >>>>> <mime-attachment> > >>>> in a stack of contexts the active pc is different for the top > context. For other than the top context, a contextâs pc will be pointing > after the send that created the context above it, so to find the pc of the > send one finds the previous pc. For the top context its pc is the active > pc. > >>>> > >>>> Typically the debugger is invoked in two different modes, > interruption or exception. When interrupted, a process is stopped at the > next suspension point (method entry or backward branch) and the top context > in the process is the context to be displayed in the debugger. When an > exception occurs the exception search machinery will find the signaling > context, the context that raised the exception, which will be below the > search machinery and the debugger invocation above that. The active pc of > the signaling context will be the of for the send of digbsl et al. > >>>> > >>>> So the distinction is important and the utility method is probably > useful. > >>>> > >>>> Do you want to remove the method simply because there are no senders > in the image? > >>>> > >>>> If so, this is indicative of a serious problem with the Pharo > development process. In the summer I ported VMMaker.oscog to Pharo 6. Now > as feenk try and build a VMMaker.oscog image on Pharo 7, the system is > broken, in part because of depreciations and in part because useful methods > (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been > removed. > >>>> > >>>> Just because a method is not in the image does not imply it is not in > use. It simply means that it is not in use in the base image. As the > system gets modularised this issue will only increase. There are lots of > collection methods that exist as a library that are not used in the base > image and removing them would clearly damage the library for users. This > is the case for lots of so-called system code. There are users out there, > like those of us in the vm team, who rely on such system code, and it is > extremely unsettling and frustrating to have that system code change all > the time. If Pharo is to be a useful platform to the vm team it has to be > more stable. > >>> -- > >>> www.feenk.com > >>> > >>> âThe smaller and more pervasive the hardware becomes, the more > physical the software gets." > >>> > >>> > >

Jan. 12, 2019

Re: [Pharo-dev] Availability of Smallapack in Pharo6.0

by Tudor Girba

Hi Nicolas, Very nice! Itâs great to have a fast library for linear algebra. Cheers, Doru > On Jan 12, 2019, at 12:33 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi, > I announce the availability of Smallapack in Pharo6. > > The ConfigurationOfSmallapack is in http://www.squeaksource.com/MetacelloRepository and there is a copy in meta repo for Pharo 3/4/5/6. > > Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments. > External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI. > Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing). > > I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance). > > But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo... > > Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me. But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned. > -- www.feenk.com âProgramming is executable philosophy."

Jan. 12, 2019

Re: [Pharo-dev] Is metacello aware of MC branches???

by Cyril Ferlicot

On Fri 11 Jan 2019 at 22:51, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Thanks, > that did not work, but I think my mistake was to write this; > > spec for: #'pharo6.0.x' > > instead of: > > spec for: #'pharo6.x'. > > Smalltalk version -> 'Pharo6.0', so probably the second dot does not match > anything... > I'll have to review more ConfigurationOf... > >> Hello, I do not have an image to check but you can find compatible by executing something like `Smalltalk metacelloPlatformAttributes` in a Pharo 6 image. >From what I wrote here: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… I guess your problem is that you tried to load the code in Pharo 6.1 and not 6.0. >>> -- Cyril Ferlicot https://ferlicot.fr

Jan. 12, 2019

Availability of Smallapack in Pharo6.0

by Nicolas Cellier

Hi, I announce the availability of Smallapack in Pharo6. The ConfigurationOfSmallapack is in http://www.squeaksource.com/MetacelloRepository and there is a copy in meta repo for Pharo 3/4/5/6. Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments. External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI. Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing). I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance). But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo... Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me. But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.

Jan. 11, 2019