December 2022 - Pharo-dev - lists.pharo.org

Re: Pharo VM Release - v9.0.21

by Guillermo Polito

Thanks Pablo!!! > El 12 dic. 2022, a las 14:30, tesonep(a)gmail.com escribiÃ³: > > Hello, > I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and Pharo 11. This VM is accessible right now from Zero-Conf, updating it in the Pharo Launcher or using the usual downloads (as described in pharo.org/download <http://pharo.org/download>). > > This version includes a series of bug fixes and upgrades on the third-party libraries. > > Changelog: > > - Implementing High resolution clock for ARM64 (Used during profiling) > - Updating third party libraries for all the graphic layer. > - Fixing a performance regression on the allocation of opcodes and fix-ups. > Cleaning only the ones that are going to be used. > Like this, this version has the same speed than before when allocating in the stack. > - Correctly handling the encoding of the command line arguments of the VM (Windows) > - Allocating the opcodes and fixup structs only once and reusing them (Reducing risk of C Stack Overflow) > > Thanks a lot, and any doubt please let me know. > Cheers, > > Pablo on behalf of the whole Pharo team. > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Dec. 12, 2022

Pharo VM Release - v9.0.21

by tesonep＠gmail.com

Hello, I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and Pharo 11. This VM is accessible right now from Zero-Conf, updating it in the Pharo Launcher or using the usual downloads (as described in pharo.org/download) This version includes a series of bug fixes and upgrades on the third-party libraries. Changelog: - Implementing High resolution clock for ARM64 (Used during profiling) - Updating third party libraries for all the graphic layer. - Fixing a performance regression on the allocation of opcodes and fix-ups. Cleaning only the ones that are going to be used. Like this, this version has the same speed than before when allocating in the stack. - Correctly handling the encoding of the command line arguments of the VM (Windows) - Allocating the opcodes and fixup structs only once and reusing them (Reducing risk of C Stack Overflow) Thanks a lot, and any doubt please let me know. Cheers, Pablo on behalf of the whole Pharo team. -- Pablo Tesone. tesonep(a)gmail.com

Dec. 12, 2022

Re: This week (49/2022) on the Pharo Issue Tracker

by Marcus Denker

> > Blocks > ====== > Status: All tests green when compiling with ConstantBlockClosure (but the option is not yet enabled by default) > Work continues to reducing the use of #home, this week by using #homeMethod instead of "home methodâ > And there are more in need of review, for example: 11965-Implement-ContextactiveHome-without-using-home #12063 https://github.com/pharo-project/pharo/pull/12063 #activeHome returns the #home if it is currently on the stack, the debugger uses that to check if a âsave and proceedâ is possible when editing code in a Block. It is implemented to search up the sender chain until it finds the #home: activeHome | methodReturnContext | self isBlockContext ifFalse: [^self]. self sender ifNil: [^nil]. methodReturnContext := self methodReturnContext. ^self sender findContextSuchThat: [:ctxt | ctxt = methodReturnContext] But it can be rewritten to do the same, but checking for the #homeMethod: activeHome | homeMethod | self isBlockContext ifFalse: [^self]. homeMethod := self homeMethod. ^self findMethodContextSuchThat: [:ctxt | ctxt method == homeMethod] With #homeMethod being implemented to delegate to the bock: Context>>homeMethod "Answer the method in which the receiver was defined, i.e. the context from which an ^-return ] should return from. Note: implemented to not need #home" ^ closureOrNil ifNil: [ self method ] ifNotNil: [ :closure | closure homeMethod ] Where, if no #outerContext is available, it asks the CompiledBlock: BlockClosure>>homeMethod "return the home method. If no #home is available due to no outerContext, use the compiledBlock" ^ (self home ifNotNil: [ :homeContext | homeContext ] ifNil: [ self compiledBlock ]) method Which uses the static #outerCode chain (CompiledBlocks encode have a back-pointer to the enclosing block or method), with #method following #outerCode until it reaches a CompiledMethod: CompiledBlock>>method "answer the compiled method that I am installed in, or nil if none.â ^self outerCode method

Dec. 9, 2022

This week (49/2022) on the Pharo Issue Tracker

by Marcus Denker

This week we merged 20 PRs. Blocks ====== Status: All tests green when compiling with ConstantBlockClosure (but the option is not yet enabled by default) Work continues to reducing the use of #home, this week by using #homeMethod instead of "home method" - 12008-Blocks-check-senders-of-compiledCode-can-we-use-homeMethod #12032 https://github.com/pharo-project/pharo/pull/12032 - Context-use-homeMethod #12007 https://github.com/pharo-project/pharo/pull/12007 - some trivial improvements batched (Compiler / Context / Blocks) #12035 https://github.com/pharo-project/pharo/pull/12035 - ConstantBlocks-fix-testIsNotTerminatedWhenItIsInsideLastTerminationMethod #12026 https://github.com/pharo-project/pharo/pull/12026 - ConstantBlocks-Fix-Announcement-Tests #12027 https://github.com/pharo-project/pharo/pull/12027 - Disablequickreturn in blocks #12053 https://github.com/pharo-project/pharo/pull/12053 Refactoring Engine ================== - Refactor make class abstract #12060 https://github.com/pharo-project/pharo/pull/12060 Features ===== - Environment: comment #allMethods, add #methods #12028 https://github.com/pharo-project/pharo/pull/12028 - help method for converting integers into correspâ¦ #11800 https://github.com/pharo-project/pharo/pull/11800 - Extend DiffMorph to make it navigable accross differences #11641 https://github.com/pharo-project/pharo/pull/11641 Fixes ===== - 12049-CI-failure-in-build-testSetUpMethodInSUnitTestsNeedsToBeInRunningProtocol #12051 https://github.com/pharo-project/pharo/pull/12051 - Fix #11995: Handle attempted creation of existing package gracefully #12048 https://github.com/pharo-project/pharo/pull/12048 - Should fix issue 11915 - Pharo compound shortcuts #11954 https://github.com/pharo-project/pharo/pull/11954 - [fix] Pharo issue # 11390: Browsing implementors/senders from source code editors doesn't browse expected selector #1298 https://github.com/pharo-spec/Spec/pull/1298 - Using version v3.0.4 of libgit to fix the 1.4.4 version in linux #1643 https://github.com/pharo-vcs/iceberg/pull/1643 - Fix Crash when invalid credentials #1642 https://github.com/pharo-vcs/iceberg/pull/1642 Cleanup ======= - Replacing baseColor method call from class to instance side #12030 https://github.com/pharo-project/pharo/pull/12030 - Fix lint issues #11978 https://github.com/pharo-project/pharo/pull/11978 - 12046 has non standard palette is always returning false #12047 https://github.com/pharo-project/pharo/pull/12047 Pharo10 ======= - [backport] CompiledCode: add #bytecodes #12031 https://github.com/pharo-project/pharo/pull/12031

Dec. 9, 2022

[Compiler] A Small experiment with Syntax Errors

by Marcus Denker

This is a small experiment about syntax errors when evaluating code. With #evaluate:, we can compile and run a DoIt, for example: Smalltalk compiler evaluate: '1+2' Imagine you evaluate a String, but it is actually not syntactically correct: Smalltalk compiler evaluate: '1+' We get an exception (while parsing), a SyntaxErrorDebugger is opened: This tool is not used often and is fairly odd, in practice we use it for two things: Look at the error message and use the (not easy to find) menu "debug calling process" to see where the eval was called to understand what went wrong (why we consructed a string of invalid code). The problem is that the tool is not easy to understand, and it is not easy to maintain as part of the debugger framework (it is a bit broken even now, especially wrt to editing and continue, which does not matter for DoIts, though). Could we no do better? Evaluating code means: - We parse the string to an AST - we translate the AST to a DoIt Method - we execute that method The error happens inside the parse phase: no method gets contructed, intead an exception is raised. There is quite some machinary to allow re-starting parsing after the error is fixed (see the exception ReparseAfterSourceEditing and how it is used, quite hard to understand). The idea that syntax errors are hard errors is quite natural. With batch compilers, there is some effort done to do some auto-repair. This was very useful in old times (punch cards!) to avoid seeing an aborted job the next morning just due to a missing comma. These days it is used to allow better error messages. But it is common to treat syntax errors as hard errors. This is seen as good as they are detected very early and the fact that compiling is not possible is seen as the goal for any kind of error. In the end, type systems try to extend this to non-syntactic problems: If a program is wrong, it should not run. If we call a method that does not exist, the program should not compile. What if we not follow this standard advice and go the exact opposite direction? Let's try: Our tools parse code after *every* keystroke. The resulting AST is used for syntax highlighting. Which means, we can parse the expression '1+â without any problem, if we use the same mode for the Parser: Smalltalk compiler options: #(+ optionParseErrors); parse: '1+' We see that the parser created an AST, with a ParseErrorNode as the argument of the message send +. This AST would used by the Syntax HighLighter, and for code completion. But it is in the end just the normal AST that the Compiler uses to compile source text to CompiledMethods. So can we not just implement the code in the compiler to compile this AST? The node implements the visitor pattern #acceptVisitor:, which calls visitParseErrorNode:. So we can add support to the compiler by just implementing OCASTTranslator>>#visitParseErrorNode: visitParseErrorNode: anErrorNode methodBuilder pushLiteralVariable: RuntimeSyntaxError binding; pushLiteral: anErrorNode; send: #signalSyntaxError: This just reads the global Variable RuntimeSyntaxError (which is subclass of Error), pushes the error node itself as an argument and sends #signalSyntaxError: signalSyntaxError: aNode "we use signalSyntaxError: instead of signal: so we can quickly check compiledMethods for syntax errors by checking the literals" ^(self new errorNode: aNode) signal To see what the compiler compiled for that expression, lets compile a DoIt method (this is what #evaluate: does to get a method to execute): compiledMethod := Smalltalk compiler noPattern: true; options: #(+ optionParseErrors); compile: '1+â So it did compile this bytecode, as expected: 49 <51> pushConstant: 1 50 <10> pushLit: RuntimeSyntaxError 51 <21> pushConstant: RBParseErrorNode() 52 <92> send: signalSyntaxError: 53 <60> send: + 54 <5C> returnTop To finish what #evaluate does, we can evaluate the compiledMethod (with a nil receiver): compiledMethod valueWithReceiver: nil arguments: #() and it works! The standard debugger opens, on the RunTimeSyntaxError: Can we do that by default for #evaluate? Go to OpalCompiler>>#evaluate and add the optionParseErrors line before compiling: ... options: #(+ optionParseErrors); doItMethod := self compile. ... If you now run Smalltalk compiler evaluate: '1+' It will open the normal debugger. What needs to be improved? - The error message is not shown other than in the debugger window title. (but all the infos to print a nice error in place is contained in the AST) - Maybe allowing to edit and proceed could be interesting (not that much for evaluate) (I will turn this into a blog post later) Marcus

Dec. 8, 2022

Re: Update Links on Pharo website

by Marcus Denker

Thanks a lot! I will review and merge the PRs ( They are here: https://github.com/pharo-project/pharo-site/pulls ) > On 6 Dec 2022, at 07:50, Pierre Misse Chanabier <pierre.misse-chanabier(a)inria.fr> wrote: > > Hello, > > I've noticed that a link to the pharo blog was missing & a user noticed the vision document link was broken. > I did a couple of quick PR to fix them. > > Pierre

Dec. 6, 2022

Update Links on Pharo website

by Pierre Misse Chanabier

Hello, I've noticed that a link to the pharo blog was missing & a user noticed the vision document link was broken. I did a couple of quick PR to fix them. Pierre

Dec. 6, 2022

Unsubscribe from pharo-dev user doesn't exist

by Juan Miguel Mora Carrera

Hi All. Sorry for the message totally unrelated to the topic, but it's been for a long time that I've been trying to unsubscribe from the list in this page: https://lists.pharo.org/empathy/list/pharo-dev.lists.pharo.org But it happens that my email account doesn't exist there, but still I'm receiving the emails. I guess my email got there via a migration from a previous list years ago. Please, could you tell me how might I unregister from the list? Thanks. Juan Miguel

Dec. 5, 2022

This week (48/2022) on the Pharo Issue Tracker.

by Marcus Denker

This week we merged 34 PRs. Features ======== - New refactoring changes preview presenter #11887 https://github.com/pharo-project/pharo/pull/11887 - Creating a method to print the "full" debug stack #11983 https://github.com/pharo-project/pharo/pull/11983 - 11544 enhance socket to show meaningful errors #11921 https://github.com/pharo-project/pharo/pull/11921 - Adding debugger extension visitor to display variables from extensions (as Chest) #402 https://github.com/pharo-spec/NewTools/pull/402 - add a Method Source View for Context #440 https://github.com/pharo-spec/NewTools/pull/440 Blocks ====== - Tests for clean and constant blocks #12015 https://github.com/pharo-project/pharo/pull/12015 - Support #isReturnSpecial on CompiledBlock #11987 https://github.com/pharo-project/pharo/pull/11987 - 11966-Implement-BlockClosurehomeMethod-without-using-home #12000 https://github.com/pharo-project/pharo/pull/12000 - StDebugger-stackSelectionMethodContext-homeMethod #445 https://github.com/pharo-spec/NewTools/pull/445 - use Context>>#homeMethod #12023 https://github.com/pharo-project/pharo/pull/12023 - 11967-Implement-findMethodContextSuchThat #12013 https://github.com/pharo-project/pharo/pull/12013 - ConstantBlock-fix-DebuggerTest #12024 https://github.com/pharo-project/pharo/pull/12024 Fixes ===== - 11844-Renaming-a-package-loses-all-the-package-extensions #11982 https://github.com/pharo-project/pharo/pull/11982 - [Compiler] fix code generation when compiling syntax errors: EnglobingError #11947 https://github.com/pharo-project/pharo/pull/11947 - fix var lookup in debugger when block pushed on stack #11989 https://github.com/pharo-project/pharo/pull/11989 - Fix print on recursive array #11916 https://github.com/pharo-project/pharo/pull/11916 - 11937-Cycling-of-Halos-does-not-work-anymore #12016 https://github.com/pharo-project/pharo/pull/12016 - Fixed #11946. Added SequenceableCollection>>truncatedToSize and a trait to test it #11988 https://github.com/pharo-project/pharo/pull/11988 - Fix: "Copy stack to clipboard" doesnt copy the whole stack #442 https://github.com/pharo-spec/NewTools/pull/442 Speed ===== - Fix slow execution time when using CharacterSet or CharacterSetCompleâ¦ #11991 https://github.com/pharo-project/pharo/pull/11991 - 12006-Performance-Regression-in-Fuel-Serialization-of-Blocks--CompiledMethods #12022 https://github.com/pharo-project/pharo/pull/12022 External Packages ================= - Updating version of tonel #12003 https://github.com/pharo-project/pharo/pull/12003 - Integrate Roassal3 v0.9.9k #12012 https://github.com/pharo-project/pharo/pull/12012 Cleanup Help ============ - Fix #11949 less help class #11950 https://github.com/pharo-project/pharo/pull/11950 - Fix spechelp problem #11999 https://github.com/pharo-project/pharo/pull/11999 - Fix 11994 Another pass to remove help classes. Waiting for the integrâ¦ #11996 https://github.com/pharo-project/pharo/pull/11996 - Removing help support #12001 https://github.com/pharo-project/pharo/pull/12001 - Removing remaing Help Topic references #444 https://github.com/pharo-spec/NewTools/pull/444 - remove help processor #443 https://github.com/pharo-spec/NewTools/pull/443 - remove Spec2-Help #1333 https://github.com/pharo-spec/Spec/pull/1333 Trival Cleanups =============== - Cleanup STON classes who show lint issue on categorization of #initiaâ¦ #11964 https://github.com/pharo-project/pharo/pull/11964 - add tag "system" #11985 https://github.com/pharo-project/pharo/pull/11985 - 12009-ProperMethodCategorizationTesttestNoUncategorizedMethods-fails-on-CI #12010 https://github.com/pharo-project/pharo/pull/12010 - Trivial-clean-Morph #12025 https://github.com/pharo-project/pharo/pull/12025

Dec. 2, 2022