- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #780: 21725-Class-builder-does-not-take-into-account-slot-definition-changes
by ci-pharo-ci-jenkins2＠inria.fr April 18, 2018

April 18, 2018

There is a new Pharo build available! The status of the build #780 was: SUCCESS. The Pull Request #1213 was integrated: "21725-Class-builder-does-not-take-into-account-slot-definition-changes" Pull request url: https://github.com/pharo-project/pharo/pull/1213 Issue Url: https://pharo.fogbugz.com/f/cases/21725 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Fun with AST evaluation
by Marcus Denker April 18, 2018

April 18, 2018

Hi, This is fun experiment: Every RBValueNode subclass evaluates to something. So why not implement a #evaluate method? This is especially fun to do for a specific context, as this means that you could evaluate every RBVariableNode to see the value. So lets implement a method in RBValueNode: evaluateWithContext: aContext | methodNode | If we want to compile a method for it, we need to wrap it into a return and a method. Like when evaluating in the debugger, we create a #DoItIn: method that will get the context as a parameter to read the values from (temps from the context, ivars from context receiver). This works like this: methodNode := RBMethodNode selector: #DoItIn: arguments: { RBVariableNode named: 'ThisContext' } body: (RBReturnNode value: self) asSequenceNode. to read temps from the context parameter, we use the rewrite method that is used by doits already: methodNode rewriteTempsForContext: aContext. and now we can execute: ^methodNode generate valueWithReceiver: aContext receiver arguments: {aContext}. For testing, I put a #haltOnce into Rectangle>>#area and then use the inspector on the context to evaluate a AST node that is a temporary variable. The screenshot shows executing self method ast assignmentNodes first variable evaluateWithContext: self and it returns correctly 104: Of course there are simpler ways to read variables by name from a context (e.g. we added #lookupSymbol: ), but #evaluateWithContext: can be called on other Nodes, too. E.g. just a #evaluate could be nice for creating Blocks programmatically (instead of calling the compiler on a Pretty-Print result like #createBlockFor: in the ParseTreeSearcher). A version that does not take context and receiver into account is this: evaluate | methodNode | methodNode := RBMethodNode selector: #DoIt body: (RBReturnNode value: self) asSequenceNode. ^methodNode generate valueWithReceiver: nil arguments: #(). and then you can do things like blockNode: = RBBlockNode body: (RBLiteralNode value: 5) asSequenceNode blockNode evaluate to create blocks. Marcus

5 7

[Pharo 7.0-dev] Build #779: 21711-Monticello-does-not-have-support-for-traits-with-slots
by ci-pharo-ci-jenkins2＠inria.fr April 18, 2018

April 18, 2018

There is a new Pharo build available! The status of the build #779 was: SUCCESS. The Pull Request #1208 was integrated: "21711-Monticello-does-not-have-support-for-traits-with-slots" Pull request url: https://github.com/pharo-project/pharo/pull/1208 Issue Url: https://pharo.fogbugz.com/f/cases/21711 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #778: 21727-move-sendNodes-to-RBProgramNode-implement-send-selfMessages-and-superMessages-like-on-CM-the-just-call-it-there
by ci-pharo-ci-jenkins2＠inria.fr April 18, 2018

April 18, 2018

There is a new Pharo build available! The status of the build #778 was: FAILURE. The Pull Request #1215 was integrated: "21727-move-sendNodes-to-RBProgramNode-implement-send-selfMessages-and-superMessages-like-on-CM-the-just-call-it-there" Pull request url: https://github.com/pharo-project/pharo/pull/1215 Issue Url: https://pharo.fogbugz.com/f/cases/21727 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #777: 21723-Opal-compiler-instances-are-created-in-huge-amount-during-a-method-compilation-from-the-browser
by ci-pharo-ci-jenkins2＠inria.fr April 17, 2018

April 17, 2018

There is a new Pharo build available! The status of the build #777 was: FAILURE. The Pull Request #1212 was integrated: "21723-Opal-compiler-instances-are-created-in-huge-amount-during-a-method-compilation-from-the-browser" Pull request url: https://github.com/pharo-project/pharo/pull/1212 Issue Url: https://pharo.fogbugz.com/f/cases/21723 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #776: 21722-Small-Cleanup-Syntax-highlighting-remove-a-reference-to-SHParserST80
by ci-pharo-ci-jenkins2＠inria.fr April 17, 2018

April 17, 2018

There is a new Pharo build available! The status of the build #776 was: SUCCESS. The Pull Request #1210 was integrated: "21722-Small-Cleanup-Syntax-highlighting-remove-a-reference-to-SHParserST80" Pull request url: https://github.com/pharo-project/pharo/pull/1210 Issue Url: https://pharo.fogbugz.com/f/cases/21722 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Pavel's ChangeLog week of 2018-02-05
by Pavel Krivanek April 17, 2018

April 17, 2018

Hi, among other less interesting things, I spent some time on existing PosixSharedMemory project. It is a UFFI binding for the LibC methods that provide support for the memory allocation between several separate processes. I significantly improved the performance by implementing the block access. Writing of 10MB byte array takes about 1 millisecond, reading of it from other image took me about 4 milliseconds. While serialization with Fuel is very fast, it opens interesting possibilities. To have a shared memory without synchronization tools is not very useful so I wrote a basic UFFI interface for the POSIX named semaphores. They are quite easy to use and work nicely with Pharo. The VM can all wait on the semaphore or it can check the status of it periodically in an image thread. It has two small disadvantages. It requires to dynamically link the next library (pthread) and they must be cleaned manually. I plan to look at System V alternative in future. Now we should write a nice framework for inter-image communication on top of it or/and adopt Seamless for it ;-) Cheers, -- Pavel

6 10

[Pharo 7.0-dev] Build #775: Revert "21429-Watchpoints-should-be-cleaned-when-system-changed"
by ci-pharo-ci-jenkins2＠inria.fr April 17, 2018

April 17, 2018

There is a new Pharo build available! The status of the build #775 was: SUCCESS. The Pull Request #1209 was integrated: "Revert "21429-Watchpoints-should-be-cleaned-when-system-changed"" Pull request url: https://github.com/pharo-project/pharo/pull/1209 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

2 1

[Pharo 7.0-dev] Build #774: 21429-Watchpoints-should-be-cleaned-when-system-changed
by ci-pharo-ci-jenkins2＠inria.fr April 17, 2018

April 17, 2018

There is a new Pharo build available! The status of the build #774 was: FAILURE. The Pull Request #1162 was integrated: "21429-Watchpoints-should-be-cleaned-when-system-changed" Pull request url: https://github.com/pharo-project/pharo/pull/1162 Issue Url: https://pharo.fogbugz.com/f/cases/21429 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #773: 21523-package-ReflectionMirrors-Primitives-needs-to-be-moved-to-the-BaselineOfPharoBootstrap
by ci-pharo-ci-jenkins2＠inria.fr April 17, 2018

April 17, 2018

There is a new Pharo build available! The status of the build #773 was: SUCCESS. The Pull Request #1051 was integrated: "21523-package-ReflectionMirrors-Primitives-needs-to-be-moved-to-the-BaselineOfPharoBootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/1051 Issue Url: https://pharo.fogbugz.com/f/cases/21523 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0