- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #848: Simplify TempVector Offset from IR

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

There is a new Pharo build available! The status of the build #848 was: FAILURE. The Pull Request #4857 was integrated: "Simplify TempVector Offset from IR" Pull request url: https://github.com/pharo-project/pharo/pull/4857 Issue Url: https://github.com/pharo-project/pharo/issues/SimplifyTempVectorOffset Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 9, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by Tudor Girba

Thanks for the roadmap. I am particularly excited about the underlying improvements, such as VM, TaskIT and TFFI, that might capture less headlines. About TaskIT, are these: > â¢ Implement a prototype of a distributed backend to execute tasks. > â¢ Implement a communication layer using Rabbit MQ > â¢ Implement the first version of a process manager for handling multiples images and workers. already available? Cheers, Doru > On Oct 7, 2019, at 4:02 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > Hi all, > > Since some time we wanted to start with this report to keep you all informed on what we are doing to achieve our goals for the release. > After ESUG we took some time to organise and we managed to put this in movement. > The idea is to post one the first week of each month (but it may vary, as you see with this one who came a bit later :P) > > Actions reportes are just dots, since we do not have the time to add a big explanation and we hope you are already involved and more or less know what we are talking about. > But do not hesitate to ask if you want more details :) > > Roadmap progress report. > September 2019 > > > Image > > Code Loading > â¢ Profiling the time spent to load code > â¢ Reimplementing a better Read/Write Buffered Stream > â¢ Improving the performance of Source writing and reading, > â¢ Improving in at least 20% the time of loading code using Metacello. > > Spec 2 > â¢ Pass on SpMillerColumnPresenter to made it of general use. > â¢ Implement a specific SpMillerLayout to handle Miller columns. > â¢ Pass on regular input ports (transmissions subsystem) to implement activation ports. > â¢ Pass on SpStyle subsystem (kind of STON based stylesheets for Morphic). > â¢ Fix SpGridLayout horizontal cell calculous. (It was broken). > â¢ Fix SpBoxLayout berderWith and padding. (It was broken). > â¢ Added contextual menus to widgets. > â¢ This functionality was completely revamped to make it work in all backends. > â¢ It was generalised to all widgets (even if not all should use it!) > â¢ Added focus order to presenters. > â¢ This is also a full revamp of old existing functionality. > â¢ it accepts you to change the default order, but it has a default order (previous implementations forced you to do the focusing by hand). > â¢ Added key binding support for all widgets. > â¢ This is also a full revamp of old exiting functionality. > > Spec2+GTK3 > â¢ callbacks can now be chained. This requires some explanation: In Gtk3 you connect to signals. And you can connect just one callback to one signal. Thankfully we control the callbacks in our side, so we modified signal callbacks to accept to chain other callbacks (then we can connect several actions to one single event, for example "keypress" or âhide"). > â¢ along with this, we reworked the callback hierarchy. > â¢ implemented inheritance in Pharo of Gtk3 objects and interfaces (this is needed to enhance control of tables and many others). > â¢ added autocompletion capabilities to SpCodePresenter. > â¢ added a mechanism to avoid duplicate signalling between the backend and the adaptors. > â¢ Fix an important leak on GtkFormView. > > NewTools > â¢ Inspector > â¢ it now implements Miller columns > â¢ Using TaskIt as backend for stepping. > â¢ extensions migrated (we are at 10% of the total of migrations needed, we will enhance this in iterative way). > â¢ Debugger > â¢ Almost complete revamp of UI. > â¢ Fix context updating (to allow commands to actually work) > â¢ Integrate new inspector. > â¢ Work on new layouts for debugger > â¢ Make an experimental tool: "playbook", to concentrate playgrounds and test some UI ideas. > > UFFI > â¢ Adding Tests > â¢ Support for kind of literals and support type definitions in literals > â¢ Documentation > â¢ Measuring performance issues on large images. > > TaskIT > â¢ Implement a prototype of a distributed backend to execute tasks. > â¢ Implement a communication layer using Rabbit MQ > â¢ Implement the first version of a process manager for handling multiples images and workers. > > VM > â¢ Fixing problem with LibGIT and Windows 1903. > â¢ Fixing the performance issues of Windows 1903 with File accesses when using solid-state 4k physical sector disks. > â¢ XCode integration > â¢ Adding an initial version to detect invalid order in the return from concurrent callbacks. > â¢ Improving the implementation of TFFI to run 50% faster in callouts. > â¢ Build of StackVM > -- feenk.com "Some battles are better lost than fought."

Oct. 9, 2019

Pharo architecture and design

by niepiekm

Hi everybody, I'd like to say that I am very impressed with how Pharo as a system is designed. I'm impressed with multiple of features it has compared to Squeak 5, its functionality as IDE. I'd like to know how was it designed from the start, how did you go about creating its architecture, document it so that developers could implement it so well. Are there any high/detail/low level design documents on which implementation was carried out? Regards, Marek -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 8, 2019

[Pharo 8.0] Build #847: 2874-clampLowHigh

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

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

Oct. 8, 2019

Re: [Pharo-dev] Seg Fault Pharo 7.0.3

by Nicolas Cellier

More on the problem that Eliot is speaking about: it can happen in these conditions: if is SIGIO is delivered while executing any trampoline transiting from SmalltalkToCStackSwitch. What happens here? We must load 64bits contents of memory (cStackPointerAddress) to the stack pointer register (SPReg = $rsp) - See genLoadCStackPointer. This is done by using the CogRTLOpcode abstract instruction MoveAwR But we have no matching instruction in IA-32 X64... We can only load a 64bits memory content in $rax So the idea is to generate this sequence (CogX64Compiler>>concretizeMoveAwR): xchgq %rsp, %rax movabsq 0x10027c338, %rax ; cStackPointerAddress xchgq %rsp, %rax That's clever because it preserves $rax which could be in use when we want to MoveAwR. But it has an unfortunate side effect: the stack pointer temporarily gets the contents of $rax and can thus temporarily point anywhere. What happens when performing Squeak SocketTest is that we use some trampolines (I guess for invoking primitives for example) and we generate SIGIO (for some reasons, there are a lot of SIGIO generated on my particular macos machine, so I can trigger the bug more easily than Eliot). We previously installed a handler for SIGIO via signal(). When we use signal(), the handler shares the stack pointer with user program. If the event is delivered in between the two xchgq instructions above, the signal handler will then use a corrupted stack pointer pointing anywhere (depending no contents of $rax) when the VM enter the signal handler function, it uses stack pointer to save some states, and corrupt a memory zone, segfault or whatever. In the case described by the opensmalltalk vm-dev thread, $rax was pointing to the generated code zone (jitted methodZone), so we corrupted the generated code and soon get punished for that. But it's probable that there might be other (rare) occurrences of this bug. Not sure if it is causing the bugs described by Sean, but it's important to use the fix from Eliot ASAP and retry. There might be other occurrence of signal(SIGIO,forceInterruptCheck) in minheadless flavour, I did not check if Eliot also corrected it, if not it should also be corrected ASAP, as should every usage of signal() be replaced by ussage of sigaction() with appropriate flags to use sigaltstack() - see Eliot's commit details. Le dim. 6 oct. 2019 Ã 12:36, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > 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. 8, 2019

Fwd: [Esug-list] Smalltalk Employment

by StÃ©phane Ducasse

> Begin forwarded message: > > From: Norm Green <norm.green(a)gemtalksystems.com> > Subject: [Esug-list] Smalltalk Employment > Date: 8 October 2019 at 18:24:28 CEST > To: esug-list(a)lists.esug.org > > GemTalk has a customer in Canada looking for Smalltalkers in the greater Toronto area. Please email if you know someone who would be interested. > > Norm > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 8, 2019

Re: [Pharo-dev] Integer #byteAt: #digitAt: portability

by ducasse

> On 8 Oct 2019, at 18:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Recently, #digitAt: was renamed to #byteAt: in Pharo 8. I totally agree that this is better. > > However, how does one write a library that needs to use this selector and wants portability with at least Pharo 7 ? > > That requires quite some effort from my side (either an ugly dynamic hack, or different source code packages, just for one method). > > Can we back port #byteAt: at least as an alias to Pharo 7 ? yes of course good idea. If you can send a PR it will be faster :) > > Sven > >

Oct. 8, 2019

Integer #byteAt: #digitAt: portability

by Sven Van Caekenberghe

Hi, Recently, #digitAt: was renamed to #byteAt: in Pharo 8. I totally agree that this is better. However, how does one write a library that needs to use this selector and wants portability with at least Pharo 7 ? That requires quite some effort from my side (either an ugly dynamic hack, or different source code packages, just for one method). Can we back port #byteAt: at least as an alias to Pharo 7 ? Sven

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by ducasse

Hello > It is indeed clearer. > Previously I thought that "migrating tools to Spec2" means migrating Spec > tools to Spec2; now I see it's rewriting all tools to use Spec2. We cannot continue to stack layers and layers of âdust". For P9 we will have to have a massive cleanup again. I started to browse the code. Now we do not have enough people looking at modularity. > However, I still wonder about all shiny new tools being developed by feenk > as part GToolkit 2 - documenter, coder, etc. as well as new iterations on > inspector, debugger. > What is their place in the grand scheme of things? Good question. Why not but not at all prices :) - tests tests tests - real models because we will not rewrite all the time everything - code review and code review [ I do not like to have subclasses of announcer and other beast to maintain I was against Glamour even if I encouraged doru to do it and retrospectively I was right :) ] Iâm not sure that we all want to code in Coder :) but we will see. Our move is to make sure that we can move slowly in the right direction: Bloc / Brick Better VM Better infrastructure (this is why I cleaned/shrunk beacon and added in P8) Better Tools What we see is that Bloc deserves 6 months of work and a nice documentation. After we will have to design widgets (or revise the ones of feenk). There is a path between innovation and making sure that companies can deploy robust applications (this is why GTK will help us for that) but we should find the right path. You see we cannot just say ok let us throw away all the PharoThings effort and others :) because we could have follow the feenk path last year but was the implication. Stef

Oct. 8, 2019

[Pharo 8.0] Build #846: add-shortcut-printer

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

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

Oct. 8, 2019