Squeak-dev October 2020

squeak-dev@lists.squeakfoundation.org

51 participants
394 discussions

Re: [squeak-dev] "Pretty Print" collections as abstract syntax trees using plain text output
by gettimothy 03 Oct '20

03 Oct '20

thank you. so, Athens tests, libcairo basic stuff verified on pharo, then install, cross-check on squeak. I have a new image spun up on the squeak-launcher 6.0alpha 19893 on the latest vm, should be fun. ---- On Sat, 03 Oct 2020 07:06:24 -0400 Alexandre Bergel <mailto:abergel@dcc.uchile.cl> wrote ---- OpenGL is not directly supported in Pharo I believe, and if it is, it will be more for aiming at 3D graphics than fast 2D. Cairo is offered using a native library which is accessed from Pharo using Athens. All the rendering of Roassal3 is made by Athens, which are ultimately translated into native calls to the libcairo using uFFI. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On 03-10-2020, at 07:56, gettimothy <mailto:gettimothy@zoho.com> wrote: I am currently familiarizing myself with the new-fangled git tools and after that will be checking to see if Squeak can run the Cairo and Athens. Also, since the diagram shows that Cairo sits on top of OpenGL, I will check the OpenGL on the pharo-9 bleeding edge and if it works, correlate with openGL on squeak6.0 alpha. funny quirk is that Roassal3 is installed on the pristine image of pharo9, and there is Athens installed, but I do not see Cairo or OpenGL installed. Perhaps they are in the Athens Baseline, or I don't know where to look. cheers. ---- On Thu, 01 Oct 2020 15:58:00 -0400 Alexandre Bergel <mailto:abergel@dcc.uchile.cl> wrote ---- The GitHub of Roassal3 is https://github.com/ObjectProfile/Roassal3 I am not sure what are the difference between Pharo and Squeak. Long time I have not looked in detail. Roassal3 comes with plenty of unit tests. I guess than the starting point is to make the test pass. Does Squeak has Athens / Cairo? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On 01-10-2020, at 16:36, Eliot Miranda <mailto:eliot.miranda@gmail.com> wrote: Hi Alexandre, where are the Rossal repositories? If we wanted to begin a port, what would be the best starting point? On Thu, Oct 1, 2020 at 12:28 PM Alexandre Bergel <mailto:abergel@dcc.uchile.cl> wrote: I think that Glamorous toolkit has its own visualization engine, unrelated to Roassal Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On 01-10-2020, at 15:47, gettimothy <mailto:gettimothy@zoho.com> wrote: Hi Eiliot, re: I don't see any mention of Rossal in the below. What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it? IIRC Glamorous Toolkit and Rossal are related; perhaps I have conflated the two. at https://feenk.com/gt/ you can see the tree graphs I have in mind. ---- On Thu, 01 Oct 2020 14:24:24 -0400 Eliot Miranda <mailto:eliot.miranda@gmail.com> wrote ---- Hi t, On Thu, Oct 1, 2020 at 11:11 AM gettimothy <mailto:gettimothy@zoho.com> wrote: Hi Eliot ---- On Thu, 01 Oct 2020 11:07:08 -0400 Eliot Miranda <mailto:eliot.miranda@gmail.com> wrote ---- Hi Tty,I don't see any mention of Rossal in the below. What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it? On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <mailto:squeak-dev@lists.squeakfoundation.org> wrote: Hi folks. Has anybody coded a way , using plain text, to output a https://en.wikipedia.org/wiki/Abstract_syntax_tree to a workspace? It would be a handy debug tool if so. An infinitely better way would be to port the Rossal visualisation system. I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model). This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation. thx I would love too, Rossal is intriguing. IIRC , "Mr. Feenk" and the board had a thread recently about "what it would take to make Rossal work on Squeak" and the discussion decided on waiting on everybody having a block of time to make that happen. I don't see any mention of Rossal in the below. What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it? Here is a cut-n-paste of that email, I saved it for future reference: Hi, Currently, at feenk we have feenkcom/opensmalltalk-vm: https://github.com/feenkcom/opensmalltalk-vm This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit. For Glamorous Toolkit we aimed for the following functionality: • Open the GUI natively and have native display quality (GUI opened through FFI calls) • Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS • Create end-user applications that are fully customisable (executable name, menus, etc) • Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI. • Have Iceberg running in native windows (which requires nested FFI callbacks) There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible. Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm. To have native GUIs we relied on Ronie Salgado’s work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch: https://github.com/pharo-project/opensmalltalk-vm/tree/headless That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback. On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour. To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package). Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56). The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17). While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62. To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI. We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper. Please let us know you would prefer to coordinate. Cheers, Tudor, on behalf of the feenk team -- http://feenk.com/ "The coherence of a trip is given by the clearness of the goal." If these things have already happened, I can push (most) other projects down the stack and take this up part-time. Let me know. Wow, that's quite an offer. I wish I could devote time to this, and probably won't be able to stay away once it starts, but for the moment I have other commitments precluding joining in this effort. If not, I briefly looked into piping output to graphviz via OSProcess . Regardless, the tool would be invaluable in groking / debugging the PEG grammars. cheers, t _,,,^..^,,,_ best, Eliot -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _,,,^..^,,,_ best, Eliot

1 0

Re: [squeak-dev] "Pretty Print" collections as abstract syntax trees using plain text output
by gettimothy 03 Oct '20

03 Oct '20

I am currently familiarizing myself with the new-fangled git tools and after that will be checking to see if Squeak can run the Cairo and Athens. Also, since the diagram shows that Cairo sits on top of OpenGL, I will check the OpenGL on the pharo-9 bleeding edge and if it works, correlate with openGL on squeak6.0 alpha. funny quirk is that Roassal3 is installed on the pristine image of pharo9, and there is Athens installed, but I do not see Cairo or OpenGL installed. Perhaps they are in the Athens Baseline, or I don't know where to look. cheers. ---- On Thu, 01 Oct 2020 15:58:00 -0400 Alexandre Bergel <abergel(a)dcc.uchile.cl> wrote ---- The GitHub of Roassal3 is https://github.com/ObjectProfile/Roassal3 I am not sure what are the difference between Pharo and Squeak. Long time I have not looked in detail. Roassal3 comes with plenty of unit tests. I guess than the starting point is to make the test pass. Does Squeak has Athens / Cairo? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On 01-10-2020, at 16:36, Eliot Miranda <mailto:eliot.miranda@gmail.com> wrote: Hi Alexandre, where are the Rossal repositories? If we wanted to begin a port, what would be the best starting point? On Thu, Oct 1, 2020 at 12:28 PM Alexandre Bergel <mailto:abergel@dcc.uchile.cl> wrote: I think that Glamorous toolkit has its own visualization engine, unrelated to Roassal Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On 01-10-2020, at 15:47, gettimothy <mailto:gettimothy@zoho.com> wrote: Hi Eiliot, re: I don't see any mention of Rossal in the below. What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it? IIRC Glamorous Toolkit and Rossal are related; perhaps I have conflated the two. at https://feenk.com/gt/ you can see the tree graphs I have in mind. ---- On Thu, 01 Oct 2020 14:24:24 -0400 Eliot Miranda <mailto:eliot.miranda@gmail.com> wrote ---- Hi t, On Thu, Oct 1, 2020 at 11:11 AM gettimothy <mailto:gettimothy@zoho.com> wrote: Hi Eliot ---- On Thu, 01 Oct 2020 11:07:08 -0400 Eliot Miranda <mailto:eliot.miranda@gmail.com> wrote ---- Hi Tty,I don't see any mention of Rossal in the below. What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it? On Oct 1, 2020, at 2:33 AM, gettimothy via Squeak-dev <mailto:squeak-dev@lists.squeakfoundation.org> wrote: Hi folks. Has anybody coded a way , using plain text, to output a https://en.wikipedia.org/wiki/Abstract_syntax_tree to a workspace? It would be a handy debug tool if so. An infinitely better way would be to port the Rossal visualisation system. I’ve talked with Alexandre and he says Rossal is designed with portability in mind (it currently runs on Pharo and BisyalWorks and predates Pharo’s current imaging model). This would give you a graphical representation of the entire tree, with the ability to attach behaviour to elements of the representation. thx I would love too, Rossal is intriguing. IIRC , "Mr. Feenk" and the board had a thread recently about "what it would take to make Rossal work on Squeak" and the discussion decided on waiting on everybody having a block of time to make that happen. I don't see any mention of Rossal in the below. What's the linkage between feek's use of either opensmalltalk-vm or Pharo's fork of it? Here is a cut-n-paste of that email, I saved it for future reference: Hi, Currently, at feenk we have feenkcom/opensmalltalk-vm: https://github.com/feenkcom/opensmalltalk-vm This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit. For Glamorous Toolkit we aimed for the following functionality: • Open the GUI natively and have native display quality (GUI opened through FFI calls) • Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS • Create end-user applications that are fully customisable (executable name, menus, etc) • Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI. • Have Iceberg running in native windows (which requires nested FFI callbacks) There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible. Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm. To have native GUIs we relied on Ronie Salgado’s work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch: https://github.com/pharo-project/opensmalltalk-vm/tree/headless That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback. On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour. To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package). Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56). The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17). While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62. To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI. We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper. Please let us know you would prefer to coordinate. Cheers, Tudor, on behalf of the feenk team -- http://feenk.com/ "The coherence of a trip is given by the clearness of the goal." If these things have already happened, I can push (most) other projects down the stack and take this up part-time. Let me know. Wow, that's quite an offer. I wish I could devote time to this, and probably won't be able to stay away once it starts, but for the moment I have other commitments precluding joining in this effort. If not, I briefly looked into piping output to graphviz via OSProcess . Regardless, the tool would be invaluable in groking / debugging the PEG grammars. cheers, t _,,,^..^,,,_ best, Eliot -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _,,,^..^,,,_ best, Eliot

1 0

Why is ModificationForbidden not an Error?
by Thiede, Christoph 03 Oct '20

03 Oct '20

Hi all, please take a short look at this behavior: TestRunner openForSuite: MorphicUIManagerTest suite. "Run Selected" <http://www.hpi.de/> At the moment (#19541), a bug in FileList2 class >> #endingSpecs (which I'm going to fix ASAP) breaks the test #testShowAllBinParts. But because ModificationForbidden is not an Error, it is not caught by the TestRunner so the whole suite run blows up, too. I could make another example by triggering a ModificationForbidden in a #drawOn: method to destroy the whole image, too. (Morph newSubclass compile: 'drawOn: x #(1) at: 1 put: 2'; new) openInHand) So my question is: Why doesn't ModificationForbidden derive from Error? Isn't it actually an error? Similar illegal operations such as "#() at: 0" or "{} at: 1 put: #foo" raise some kind of Error, too. Everything I learned so far about Squeak's exception framework tells me that you should have a very good reason if you design an exception neither to derive from Error, nor from Notification. At the moment, we only do have 9 exceptions (bad pun ...) to this rule (and I'm not even sure whether MCNoChangesException couldn't be a notification, and Abort does not even have senders in the Trunk). I'd be happy if you could give me some pointers on why ModificationForbidden does not follow this rule. How can we deal with this in order to fix the bugs/unexpected behaviors mentioned above? Possibly related stuff: * http://forum.world.st/Squeak-s-AssertionFailure-vs-SUnit-s-TestFailure-td51… * http://forum.world.st/The-Trunk-Kernel-eem-1294-mcz-td5112196.html * http://forum.world.st/The-Trunk-Kernel-eem-1317-mcz-tp5113273p5113433.html Best, Christoph

12 53

The Trunk: Kernel-dtl.1343.mcz
by commits＠source.squeak.org 03 Oct '20

03 Oct '20

David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-dtl.1343.mcz ==================== Summary ==================== Name: Kernel-dtl.1343 Author: dtl Time: 2 October 2020, 10:26:27.397227 pm UUID: 1fcc87a9-8b18-4a84-b240-4dd9f24cfa46 Ancestors: Kernel-eem.1342, Kernel-ct.1321 Merge Kernel-ct.1321 per http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-October/211967.… =============== Diff against Kernel-eem.1342 =============== Item was changed: + Error subclass: #ModificationForbidden - Exception subclass: #ModificationForbidden instanceVariableNames: 'mirror object fieldIndex newValue retrySelector resumptionValue' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Exceptions'! + !ModificationForbidden commentStamp: 'ct 4/9/2020 19:49' prior: 0! + This error is raised when attempting to mutate a read-only object. - !ModificationForbidden commentStamp: 'eem 3/11/2020 15:46' prior: 0! - This exception is raised when attempting to mutate a read-only object. + My instances describe the necessary state to be able to reproduce the modification via the #retryModification protocol. - My instances have 5 fields to be able to reproduce the modification via the retryModification method. + Instance Variables + mirror: <Context | Behavior | Array> + object: <Object> + fieldIndex: <SmallInteger | nil> + newValue: <Object> + resumptionValue: <Object> + retrySelector: <Symbol> + + mirror + - the object that will perform the modification on object if modificationRetried + + object + - read-only object that attempted to mutate + + fieldIndex + - index of the field in the object mutated, relevant for the corresponding selector + + newValue + - value that was attempted to be stored into the read-only object + + resumptionValue + - value that will be returned when the ModificationForbidden is resumed + + retrySelector + - selector that can be used to reproduce the mutation (#object:basicAt:put:, #object:instVarAt:put:, etc.)! - mirror <Context|Behavior|Array> the object that will perform the modification on object if modificationRetried - object <Object> read-only object that attempted to mutate - index <SmallInteger | nil> index of the field in the object mutated, relevant for the corresponding selector - value <Object> value that was attempted to be stored into the read-only object - selector <Symbol> selector that can be used to reproduce the mutation (#object:basicAt:put:, #object:instVarAt:put:, etc)! Item was removed: - ----- Method: ModificationForbidden>>defaultAction (in category 'priv handling') ----- - defaultAction - UnhandledError signalForException: self! Item was changed: ----- Method: ModificationForbidden>>indexedMessageText (in category 'printing') ----- indexedMessageText + + ^ 'Cannot modify field {2} of read-only object {1}' translated + format: { + self printObject: object. + fieldIndex }! - ^String streamContents: - [ :s | - s << ' '. - self printObject: object on: s. - s << ' is read-only, hence its field '. - fieldIndex printOn: s. - s << ' cannot be modified with '. - self printObject: newValue on: s]! Item was added: + ----- Method: ModificationForbidden>>isResumable (in category 'priv handling') ----- + isResumable + + ^ true! Item was changed: ----- Method: ModificationForbidden>>nonIndexedMessageText (in category 'printing') ----- nonIndexedMessageText + + ^ 'Cannot execute {2} on read-only object {1}' translated + format: { + self printObject: object. + retrySelector printString }! - ^String streamContents: - [ :s | - s << ' '. - self printObject: object on: s. - s << ' is read-only, hence its selector '. - s << retrySelector. - s << ' cannot be executed with '. - self printObject: newValue on: s]! Item was added: + ----- Method: ModificationForbidden>>printObject: (in category 'private') ----- + printObject: obj + + ^ [obj printString] + ifError: ['<cannot print object>' translated]! Item was removed: - ----- Method: ModificationForbidden>>printObject:on: (in category 'printing') ----- - printObject: obj on: s - [obj printOn: s] - on: Exception - do: [ :ex | s << '<cannot print object>' ]! Item was changed: ----- Method: ModificationForbidden>>resume (in category 'controlling') ----- resume + "Return from the message that signaled the receiver." - "Roll back thisContext to self and resume. Execute unwind blocks when rolling back. ASSUMES self is a sender of thisContext" + ^ self resume: resumptionValue! - self resume: resumptionValue!

1 0

The Trunk: Kernel-ct.1321.mcz
by commits＠source.squeak.org 03 Oct '20

03 Oct '20

David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ct.1321.mcz ==================== Summary ==================== Name: Kernel-ct.1321 Author: ct Time: 9 April 2020, 7:55:56.724949 pm UUID: 6f8c6c8d-a379-5f46-b774-587e81ddb067 Ancestors: Kernel-eem.1319 Integrates ModificationForbidden into Error hierarchy. This makes ModificationForbidden catchable by #ifError:, TestResult exError and others. See also: http://forum.world.st/Why-is-ModificationForbidden-not-an-Error-td5114717.h… Further refactorings applied: - Update class comment (use Smalltalk-typical format, update instvar names and don't hardcode their count) - Use #translated and #format: for message texts - Update method comment of #resume which was copied from Context =============== Diff against Kernel-eem.1319 =============== Item was changed: + Error subclass: #ModificationForbidden - Exception subclass: #ModificationForbidden instanceVariableNames: 'mirror object fieldIndex newValue retrySelector resumptionValue' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Exceptions'! + !ModificationForbidden commentStamp: 'ct 4/9/2020 19:49' prior: 0! + This error is raised when attempting to mutate a read-only object. - !ModificationForbidden commentStamp: 'eem 3/11/2020 15:46' prior: 0! - This exception is raised when attempting to mutate a read-only object. + My instances describe the necessary state to be able to reproduce the modification via the #retryModification protocol. - My instances have 5 fields to be able to reproduce the modification via the retryModification method. + Instance Variables + mirror: <Context | Behavior | Array> + object: <Object> + fieldIndex: <SmallInteger | nil> + newValue: <Object> + resumptionValue: <Object> + retrySelector: <Symbol> + + mirror + - the object that will perform the modification on object if modificationRetried + + object + - read-only object that attempted to mutate + + fieldIndex + - index of the field in the object mutated, relevant for the corresponding selector + + newValue + - value that was attempted to be stored into the read-only object + + resumptionValue + - value that will be returned when the ModificationForbidden is resumed + + retrySelector + - selector that can be used to reproduce the mutation (#object:basicAt:put:, #object:instVarAt:put:, etc.)! - mirror <Context|Behavior|Array> the object that will perform the modification on object if modificationRetried - object <Object> read-only object that attempted to mutate - index <SmallInteger | nil> index of the field in the object mutated, relevant for the corresponding selector - value <Object> value that was attempted to be stored into the read-only object - selector <Symbol> selector that can be used to reproduce the mutation (#object:basicAt:put:, #object:instVarAt:put:, etc)! Item was removed: - ----- Method: ModificationForbidden>>defaultAction (in category 'priv handling') ----- - defaultAction - UnhandledError signalForException: self! Item was changed: ----- Method: ModificationForbidden>>indexedMessageText (in category 'printing') ----- indexedMessageText + + ^ 'Cannot modify field {2} of read-only object {1}' translated + format: { + self printObject: object. + fieldIndex }! - ^String streamContents: - [ :s | - s << ' '. - self printObject: object on: s. - s << ' is read-only, hence its field '. - fieldIndex printOn: s. - s << ' cannot be modified with '. - self printObject: newValue on: s]! Item was added: + ----- Method: ModificationForbidden>>isResumable (in category 'priv handling') ----- + isResumable + + ^ true! Item was changed: ----- Method: ModificationForbidden>>nonIndexedMessageText (in category 'printing') ----- nonIndexedMessageText + + ^ 'Cannot execute {2} on read-only object {1}' translated + format: { + self printObject: object. + retrySelector printString }! - ^String streamContents: - [ :s | - s << ' '. - self printObject: object on: s. - s << ' is read-only, hence its selector '. - s << retrySelector. - s << ' cannot be executed with '. - self printObject: newValue on: s]! Item was added: + ----- Method: ModificationForbidden>>printObject: (in category 'private') ----- + printObject: obj + + ^ [obj printString] + ifError: ['<cannot print object>' translated]! Item was removed: - ----- Method: ModificationForbidden>>printObject:on: (in category 'printing') ----- - printObject: obj on: s - [obj printOn: s] - on: Exception - do: [ :ex | s << '<cannot print object>' ]! Item was changed: ----- Method: ModificationForbidden>>resume (in category 'controlling') ----- resume + "Return from the message that signaled the receiver." - "Roll back thisContext to self and resume. Execute unwind blocks when rolling back. ASSUMES self is a sender of thisContext" + ^ self resume: resumptionValue! - self resume: resumptionValue!

1 0

The Inbox: Tools-ct.986.mcz
by commits＠source.squeak.org 03 Oct '20

03 Oct '20

Christoph Thiede uploaded a new version of Tools to project The Inbox: http://source.squeak.org/inbox/Tools-ct.986.mcz ==================== Summary ==================== Name: Tools-ct.986 Author: ct Time: 2 September 2020, 4:55:38.538083 pm UUID: b4cdf611-f04b-0b40-8f61-34429f414cca Ancestors: Tools-ct.985 Fixes MNU when adding senders of a non-string literal to a message trace (at the end, FindText was set to a number or something similar). Improves multilingual support. =============== Diff against Tools-ct.985 =============== Item was changed: ----- Method: MessageTrace>>addParentMethodsSending: (in category 'building') ----- addParentMethodsSending: selectorSymbol + ^ self systemNavigation + headingAndAutoselectForLiteral: selectorSymbol + do: [:label :autoSelect | + | methodsList | + methodsList := self systemNavigation allCallsOn: selectorSymbol. + methodsList ifEmpty: [ + ^ self inform: ('There are no {1}' translated format: {label})]. + self - | methodsList | - (methodsList := self systemNavigation allCallsOn: selectorSymbol) isEmpty - ifTrue: - [ ^(PopUpMenu labels: ' OK ') - startUpWithCaption: 'There are no methods that send ', selectorSymbol ] - ifFalse: - [ self addParentMessages: methodsList + autoSelectString: autoSelect] - autoSelectString: selectorSymbol ] !

6 10

Curious history
by Robert Withers 02 Oct '20

02 Oct '20

I am curious. Who was the original author of the VMMaker Tool? -- Kindly, rabbit . .. ... '...^,^

5 47

The Trunk: Compiler-eem.443.mcz
by commits＠source.squeak.org 02 Oct '20

02 Oct '20

Eliot Miranda uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-eem.443.mcz ==================== Summary ==================== Name: Compiler-eem.443 Author: eem Time: 2 October 2020, 12:25:28.42646 pm UUID: c0b19571-c72e-4d7e-9081-41b61e767e6b Ancestors: Compiler-eem.442 Decompiler/CompiledCode: startKeysToBlockExtents has moved from CompiledMethod to DebuggerMethodMap. =============== Diff against Compiler-eem.442 =============== Item was removed: - ----- Method: CompiledBlock>>startKeysToBlockExtents (in category '*Compiler-support') ----- - startKeysToBlockExtents - ^self homeMethod startKeysToBlockExtents! Item was removed: - ----- Method: CompiledMethod>>blockExtentsInto:from:to:method:numberer: (in category '*Compiler-support') ----- - blockExtentsInto: aDictionary from: initialPC to: endPC method: method numberer: numbererBlock - "Support routine for startpcsToBlockExtents" - | pcs extentStart locator scanner blockSizeOrMethodOrLocator | - self flag: 'belongs in DebuggerMethodMap'. - extentStart := numbererBlock value. - locator := BlockStartLocator new. - scanner := InstructionStream new method: method pc: initialPC. - pcs := OrderedCollection new. - [pcs addLast: scanner pc. - scanner pc <= endPC] whileTrue: - [blockSizeOrMethodOrLocator := scanner interpretNextInstructionFor: locator. - blockSizeOrMethodOrLocator ~~ locator ifTrue: - [blockSizeOrMethodOrLocator isInteger - ifTrue: - [self - blockExtentsInto: aDictionary - from: scanner pc - to: scanner pc + blockSizeOrMethodOrLocator - 1 - method: method - numberer: numbererBlock. - scanner pc: scanner pc + blockSizeOrMethodOrLocator] - ifFalse: - [self assert: blockSizeOrMethodOrLocator isCompiledBlock. - self - blockExtentsInto: aDictionary - from: blockSizeOrMethodOrLocator initialPC - to: blockSizeOrMethodOrLocator endPC - method: blockSizeOrMethodOrLocator - numberer: numbererBlock]]]. - aDictionary - at: (method isCompiledBlock - ifTrue: [method] - ifFalse: [initialPC]) - put: (extentStart to: numbererBlock value). - ^aDictionary! Item was removed: - ----- Method: CompiledMethod>>startKeysToBlockExtents (in category '*Compiler-support') ----- - startKeysToBlockExtents - "Answer a Dictionary of start key to Interval of blockExtent, using the - identical numbering scheme described in and orchestrated by - BlockNode>>analyseArguments:temporaries:rootNode:. A start key - identifies a block within a method and is either the startpc for an - embedded block or the block method itself for a full block. This is - used in part to find the temp names for any block in a method, as - needed by the debugger. The other half is to recompile the method, - obtaining the temp names for each block extent. By indirecting through - the blockExtent instead of using the startpc directly we decouple the - debugger's access to temp names from the exact bytecode; insulating - debugging from minor changes in the compiler (e.g. changes in literal - pooling, adding prefix bytecodes, adding inst vars to CompiledMethod - in literals towards the end of the literal frame, etc). If the recompilation - doesn't produce exactly the same bytecode at exactly the same offset - no matter; the blockExtents will be the same." - | index | - self flag: 'belongs in DebuggerMethodMap'. - index := 0. - ^self - blockExtentsInto: self newBlockStartMap - from: self initialPC - to: self endPC - method: self - numberer: [| value | value := index. index := index + 2. value]! Item was changed: ----- Method: Decompiler>>mapFromBlockKeysIn:toTempVarsFrom:constructor: (in category 'initialize-release') ----- mapFromBlockKeysIn: aMethod toTempVarsFrom: schematicTempNamesString constructor: aDecompilerConstructor + "Answer a (n Identity) Dictionary from block start key to sequence of TermpVarNode & RemoteTempVarNode" | startMap tempMap | + "This rather odd construct is to avoid recursion if we used aMethod methodNode startKeysToBlockExtents, + which will invoke this Decompiler if a method has no source." + startMap := (DebuggerMethodMap + forMethod: aMethod + methodNode: nil) startKeysToBlockExtents. - startMap := aMethod startKeysToBlockExtents. tempMap := aMethod mapFromBlockKeys: (startMap keys asArray sort: [:a :b| (startMap at: a) first <= (startMap at: b) first]) toSchematicTemps: schematicTempNamesString. tempMap keysAndValuesDo: [:startKey :tempNameTupleVector| tempNameTupleVector isEmpty ifFalse: [| subMap numTemps tempVector | subMap := Dictionary new. "Find how many temp slots there are (direct & indirect temp vectors) and for each indirect temp vector find how big it is." tempNameTupleVector do: [:tuple| tuple last isArray ifTrue: [subMap at: tuple last first put: tuple last last. numTemps := tuple last first] ifFalse: [numTemps := tuple last]]. "create the temp vector for this scope level." tempVector := Array new: numTemps. "fill it in with any indirect temp vectors" subMap keysAndValuesDo: [:index :size| tempVector at: index put: (Array new: size)]. "fill it in with temp nodes." tempNameTupleVector do: [:tuple| | itv | tuple last isArray ifTrue: [itv := tempVector at: tuple last first. itv at: tuple last last put: (aDecompilerConstructor codeTemp: tuple last last - 1 named: tuple first)] ifFalse: [tempVector at: tuple last put: (aDecompilerConstructor codeTemp: tuple last - 1 named: tuple first)]]. "replace any indirect temp vectors with proper RemoteTempVectorNodes" subMap keysAndValuesDo: [:index :size| tempVector at: index put: (aDecompilerConstructor codeRemoteTemp: index remoteTemps: (tempVector at: index))]. "and update the entry in the map" tempMap at: startKey put: tempVector]]. ^tempMap!

1 0

The Trunk: Compiler-eem.442.mcz
by commits＠source.squeak.org 02 Oct '20

02 Oct '20

Eliot Miranda uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-eem.442.mcz ==================== Summary ==================== Name: Compiler-eem.442 Author: eem Time: 2 October 2020, 12:24:11.925015 pm UUID: b9e6bdcf-95df-433b-8bbb-b2168a1e8a90 Ancestors: Compiler-pre.441 Make sure that the default return value of a doit is self, not nil. =============== Diff against Compiler-pre.441 =============== Item was changed: ----- Method: Parser>>method:context: (in category 'expression types') ----- method: doit context: ctxt " pattern [ | temporaries ] block => MethodNode." | sap blk prim temps messageComment methodNode | sap := self pattern: doit inContext: ctxt. "sap={selector, arguments, precedence}" self properties selector: (sap at: 1). encoder selector: (sap at: 1). (sap at: 2) do: [:argNode | argNode beMethodArg]. doit ifFalse: [self pragmaSequence]. temps := self temporaries. messageComment := currentComment. currentComment := nil. doit ifFalse: [self pragmaSequence]. prim := self pragmaPrimitives. + self statements: #() innerBlock: false blockNode: BlockNode new. - self statements: #() innerBlock: doit. blk := parseNode. doit ifTrue: [blk returnLast] ifFalse: [blk returnSelfIfNoOther: encoder]. hereType == #doIt ifFalse: [^self expected: 'Nothing more']. methodNode := self newMethodNode comment: messageComment. methodNode selector: (sap at: 1) arguments: (sap at: 2) precedence: (sap at: 3) temporaries: temps block: blk encoder: encoder primitive: prim properties: properties. self interactive ifTrue: [self declareUndeclaredTemps: methodNode. self removeUnusedTemps: methodNode]. ^methodNode!

1 0

The Trunk: Tests-eem.438.mcz
by commits＠source.squeak.org 02 Oct '20

02 Oct '20

Eliot Miranda uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-eem.438.mcz ==================== Summary ==================== Name: Tests-eem.438 Author: eem Time: 2 October 2020, 12:20:47.276738 pm UUID: 13a36e35-c178-4b73-ba5b-0c66407c6d1a Ancestors: Tests-ct.437 ClosureCompilerTest: startKeysToBlockExtents has moved from CompiledMethod to DebuggerMethodMap. =============== Diff against Tests-ct.437 =============== Item was changed: ----- Method: ClosureCompilerTest>>testBlockNumbering (in category 'tests') ----- testBlockNumbering "Test that the compiler and CompiledMethod agree on the block numbering of a substantial doit." "self new testBlockNumbering" self bytecodeSetClassesForTests do: [:class| | methodNode method tempRefs | methodNode := Parser new encoderClass: EncoderForV3PlusClosures; parse: 'foo | numCopiedValuesCounts | numCopiedValuesCounts := Dictionary new. 0 to: 32 do: [:i| numCopiedValuesCounts at: i put: 0]. Transcript clear. Smalltalk allClasses remove: GeniePlugin; do: [:c| {c. c class} do: [:b| Transcript nextPut: b name first; endEntry. b selectorsAndMethodsDo: [:s :m| | pn | m isQuick not ifTrue: [pn := b parserClass new encoderClass: EncoderForV3PlusClosures; parse: (b sourceCodeAt: s) class: b. pn generate. [pn accept: nil] on: MessageNotUnderstood do: [:ex| | msg numCopied | msg := ex message. (msg selector == #visitBlockNode: and: [(msg argument instVarNamed: ''optimized'') not]) ifTrue: [numCopied := (msg argument computeCopiedValues: pn) size. numCopiedValuesCounts at: numCopied put: (numCopiedValuesCounts at: numCopied) + 1]. msg setSelector: #==. ex resume: nil]]]]]. numCopiedValuesCounts' class: Object. method := methodNode generate. tempRefs := methodNode encoder blockExtentsToTempsMap. + self assert: tempRefs keys asSet equals: method debuggerMap startKeysToBlockExtents values asSet]! - self assert: tempRefs keys asSet equals: method startKeysToBlockExtents values asSet]! Item was changed: ----- Method: ClosureCompilerTest>>testBlockNumberingForInjectInto (in category 'tests') ----- testBlockNumberingForInjectInto "Test that the compiler and CompiledMethod agree on the block numbering of Collection>>inject:into: and that temp names for inject:into: are recorded." "self new testBlockNumberingForInjectInto" self bytecodeSetClassesForTests do: [:class| | methodNode method tempRefs | methodNode := Parser new encoderClass: EncoderForV3PlusClosures; parse: (Collection sourceCodeAt: #inject:into:) class: Collection. method := methodNode generate. tempRefs := methodNode encoder blockExtentsToTempsMap. + self assert: tempRefs keys asSet equals: method debuggerMap startKeysToBlockExtents values asSet. - self assert: tempRefs keys asSet equals: method startKeysToBlockExtents values asSet. self assert: ((tempRefs includesKey: (0 to: 6)) and: [(tempRefs at: (0 to: 6)) hasEqualElements: #(('thisValue' 1) ('binaryBlock' 2) ('nextValue' (3 1)))]). self assert: ((tempRefs includesKey: (2 to: 4)) and: [(tempRefs at: (2 to: 4)) hasEqualElements: #(('each' 1) ('binaryBlock' 2) ('nextValue' (3 1)))])]!

1 0

Jump to page: