October 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #839: Document and Improve TempVector Access

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

There is a new Pharo build available! The status of the build #839 was: SUCCESS. The Pull Request #4844 was integrated: "Document and Improve TempVector Access" Pull request url: https://github.com/pharo-project/pharo/pull/4844 Issue Url: https://github.com/pharo-project/pharo/issues/ImproveTempVectorAccess Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 7, 2019

[Pharo 8.0] Build #838: Remove `bounds` ivar from AthensBalloonPath

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

There is a new Pharo build available! The status of the build #838 was: SUCCESS. The Pull Request #4842 was integrated: "Remove `bounds` ivar from AthensBalloonPath" Pull request url: https://github.com/pharo-project/pharo/pull/4842 Issue Url: https://github.com/pharo-project/pharo/issues/4549 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 7, 2019

[Pharo 8.0] Build #837: Rename "Move to class package" to "Move to the defining class"

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

There is a new Pharo build available! The status of the build #837 was: FAILURE. The Pull Request #4841 was integrated: "Rename "Move to class package" to "Move to the defining class"" Pull request url: https://github.com/pharo-project/pharo/pull/4841 Issue Url: https://github.com/pharo-project/pharo/issues/4451 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2019

about common command

by ducasse

Hi I played a bit to turn smart suggestion actions into commander2 commands. It works :). Now with CM2 we do not have to have a class per command. We can create an instance. Now I was wondering what we prefer - using classes + we can dispatch later (for example suggestions dispatch on nodes message to register to specific AST node and the new behavior can be plugged modularly using extension + free registration - we create one class per command - using instances + no need to create one class. - we need to build a registration and query mechanism - extension will require to change or annotate somehow the created instances . So I have the impression that using classes is better. Setf

Oct. 6, 2019

Re: [Pharo-dev] Easy first issues for Pharo contributors?

by Cyril Ferlicot

On Sun 6 Oct 2019 at 16:12, James Foster <Smalltalk(a)jgfoster.net> wrote: > All good suggestions. I especially like the executable examples idea since > that will demonstrate understanding of the code but still be easy to > describe and easy to confirm. Thanks! > Hi, Adding method, class and package comments is also simple and great for the community :) > > > -- Cyril Ferlicot https://ferlicot.fr

Oct. 6, 2019

Re: [Pharo-dev] Easy first issues for Pharo contributors?

by James Foster

All good suggestions. I especially like the executable examples idea since that will demonstrate understanding of the code but still be easy to describe and easy to confirm. Thanks! > On Oct 6, 2019, at 3:10 AM, ducasse <stepharo(a)netcourrier.com> wrote: > > > >> On 6 Oct 2019, at 07:04, James Foster <Smalltalk(a)JGFoster.net> wrote: >> >> Hi Pharo developers, >> >> I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues. > > Excellent idea! > >> Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones. > > It would be super cool to add executable examples to number and others. > >> My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful). > > Yes. > Once back in 2005 I gave as exercise to write tests for collections (because they were none back then) after I reviewed revise them and committed them. > So looking at coverage of classes may be a nice option too. > > I think that what you can also ask them is to > - reproduce issue > - comment issue > This is an important aspect too. > > Stef >> >> James Foster > > > >

Oct. 6, 2019

Re: [Pharo-dev] Seg Fault Pharo 7.0.3

by Eliot Miranda

Hi Sean, Hi All, this may be because of the issue described here: http://forum.world.st/Difficult-to-debug-VM-crash-with-full-blocks-and-Sist… This issue is characterized by the system crashing soon after start up when some significant i/o is done, typically either to files or sockets. It affects macOS only and may indeed affect only 64-bits. We have strong evidence that it is caused by the dynamic linker being invoked in the signal handler for SIGIO when the signal is delivered while the VM is executing JITted code. The symptom that causes the crash is corruption of a particular jitted methodâs machine code, eg Delay class>>#startEventLoop, and we believe that the corruption is caused by the linker when it misinterprets a jitted Smalltalk stack frame as an ABI-compliant stack frame and attempts to scan code to link it. Our diagnosis is speculative; this is extremely hard to reproduce. Typically in repeating a crashing run SIGIO may no longer be delivered at the same point because any remote server has now woken up and delivers results sooner, etc. However, Nicolas Cellier and I are both confident that we have correctly identified the bug. The fix is simple; SIGIO should be delivered on a dedicated signal stack (see sigaltstack(2)). I committed a fix yesterday evening and we should see within a week or so if these crashes have disappeared. I encourage the Pharo vm maintainers to build and release vms that include https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c24970eb2859a47406… asap. Cheers, Eliot _,,,^..^,,,_ (phone) > On Oct 3, 2019, at 1:24 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Segmentation fault Thu Oct 3 15:52:33 2019 > > > VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 > Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > C stack backtrace & registers: > rax 0x0000000124380000 rbx 0x00007ffeebd00050 rcx 0x0000000000468260 rdx > 0x0000000000dd6800 > rdi 0x0000000124cee5a0 rsi 0x0000000124cee5a0 rbp 0x00007ffeebcffe50 rsp > 0x00007ffeebcffe50 > r8 0x00007fff3f2cefe5 r9 0x0000000000000b00 r10 0x0000000000006000 r11 > 0xfffffffffcd8d5a0 > r12 0x0000000000000002 r13 0x0000000035800000 r14 0x00007ffeebd00064 r15 > 0x0000000000002800 > rip 0x00007fff630f7d09 > 0 libsystem_platform.dylib 0x00007fff630f7d09 > _platform_memmove$VARIANT$Haswell + 41 > 1 Pharo 0x0000000103f52642 reportStackState > + 952 > 2 Pharo 0x0000000103f52987 sigsegv + 174 > 3 libsystem_platform.dylib 0x00007fff630fab3d _sigtramp + 29 > 4 ??? 0x0000058900000a00 0x0 + > 6085968660992 > 5 libGLImage.dylib 0x00007fff3f2ce29e > glgProcessPixelsWithProcessor + 2149 > 6 AMDRadeonX5000GLDriver 0x000000010db16db1 glrATIStoreLevels > + 1600 > 7 AMDRadeonX5000GLDriver 0x000000010db52c83 > glrAMD_GFX9_LoadSysTextureStandard + 45 > 8 AMDRadeonX5000GLDriver 0x000000010db519bb glrUpdateTexture > + 1346 > 9 libGPUSupportMercury.dylib 0x00007fff5181279d > gpusLoadCurrentTextures + 591 > 10 AMDRadeonX5000GLDriver 0x000000010db5a099 gldUpdateDispatch > + 397 > 11 GLEngine 0x00007fff3ff72078 > gleDoDrawDispatchCore + 629 > 12 GLEngine 0x00007fff3ff16369 > glDrawArraysInstanced_STD_Exec + 264 > 13 GLEngine 0x00007fff3ff1625a > glDrawArrays_UnpackThread + 40 > 14 GLEngine 0x00007fff3ff6dce1 gleCmdProcessor + > 77 > 15 libdispatch.dylib 0x00007fff62ec2dcf > _dispatch_client_callout + 8 > 16 libdispatch.dylib 0x00007fff62ecea2c > _dispatch_lane_barrier_sync_invoke_and_complete + 60 > 17 GLEngine 0x00007fff3fec4b85 > glFlush_ExecThread + 15 > 18 Pharo 0x0000000103f4cc62 > -[sqSqueakOSXOpenGLView drawRect:flush:] + 314 > 19 Pharo 0x0000000103f4cb22 - > ... > > Smalltalk stack dump: > 0x7ffeebd14238 M DelaySemaphoreScheduler>unscheduleAtTimingPriority > 0x10fab3ad0: a(n) DelaySemaphoreScheduler > 0x7ffeebd14270 M [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x10fab3ad0: a(n) DelaySemaphoreScheduler > 0x1125923f8 s BlockClosure>ensure: > 0x111e88d30 s > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x112590a50 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: > 0x111e88e08 s [] in BlockClosure>newProcess > > Most recent primitives > @ > actualScreenSize > millisecondClockValue > tempAt: > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 6, 2019

Re: [Pharo-dev] Easy first issues for Pharo contributors?

by ducasse

> On 6 Oct 2019, at 07:04, James Foster <Smalltalk(a)JGFoster.net> wrote: > > Hi Pharo developers, > > I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues. Excellent idea! > Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones. It would be super cool to add executable examples to number and others. > My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful). Yes. Once back in 2005 I gave as exercise to write tests for collections (because they were none back then) after I reviewed revise them and committed them. So looking at coverage of classes may be a nice option too. I think that what you can also ask them is to - reproduce issue - comment issue This is an important aspect too. Stef > > James Foster

Oct. 6, 2019

Easy first issues for Pharo contributors?

by James Foster

Hi Pharo developers, I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues. Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones. My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful). James Foster

Oct. 6, 2019

[Pharo 8.0] Build #836: Spec2-sync

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

There is a new Pharo build available! The status of the build #836 was: SUCCESS. The Pull Request #4811 was integrated: "Spec2-sync" Pull request url: https://github.com/pharo-project/pharo/pull/4811 Issue Url: https://github.com/pharo-project/pharo/issues/Spec2 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2019