March 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

On 03/06/2018 06:21 AM, Guillermo Polito wrote: > Hi Dale! > > On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > > On 03/05/2018 09:07 AM, Guillermo Polito wrote: > > On the other side, there is the fact that Metacello baselines > are so far nice to describe release project dependencies, but > they are not so nice to describe subprojects/development > dependencies that may get edited along with the parent > project. Kind of what we used to do with #bleedingEdge. I feel > this is a complex problem, that not even SBT or maven that are > there since years are capable of solving nicely... Tode and > Iceberg metacello integration try to solve this problem by > "ignoring the dependency and using the loaded repository" but > this may not be successful either... > > > I have not been following this thread in detail, but this comment > leads me to believe that the issue that you guys are running into > has to do with trying to ongoing distributed development across > multiple projects and multiple platform versions ... > > > I don't know exactly the case of Calypso, but I don't think it is > being maintained for other than latest Pharo 7. > > The Calypso case as I understand it is that it has a couple of > dependencies > > Â Calypso > Â Â | - commander > Â Â | - class annotations > > The three projects are hosted in different repositories, but Denis > wants to work on "bleeding edge" of the three of them at the same time. > Then when he loads calypso in a new image, if he just uses a baseline > he will load specific versions of the dependencies and not the latest > ones... > > I think this is the particular use case for locking, isn't it? Yes this is exactly the use case for locking. > > > If so then I think that the moral equivalent of #bleedingEdge > should be a branch structure along the lines of: > > Â master branch --- the project release that is known to work on > all supported platform versions. > Â dev_pharo6Â Â Â Â Â --- the current #bleedingEdge for Pharo6.0 > Â dev_pharo7Â Â Â Â Â --- the current #bleedingEdge for Pharo7.0 > > In an image where you want to use the dev_pharo7 for a project, > you do a Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE > loading the project ... if there are multiple projects that need > to all coordinate development then you follow the same convention > and use a Metacello lock for each of the projects ... Executing > expressions to lock projects is tedious to use and manage. > > > It is not that complicated I think ^^. I have found that "load specifications" are much easier to work with than "load expressions", similar to the way class definitions are superior to smalltalk code for creating classes, one can reason about a "load specification" for example it is possible to merge two load specifications to produce a single load specification whereas this kind of thing is not possible if you are given two arbitrary Smalltalk expressions to merge ... > > > In tODE I started using project entries[1] that are downloaded to > disk and shared by multiple images that allow a developer to > specify what branch/tag/commit they are interested in using ... > each image that is started up in a "cluster" uses the project > entry to do a Metacello lock on the project "automagically"... if > there is a series of projects where the developer needs to use > dev_pharo6 they can arrange to edit the project entry to reflect > the proper branches for the set of projects that need special > _development_ treatment ... these .ston files can be shared > amongst groups of developers ... of course once the local clones > of these projects are on the local disk, then it is up to the > developer (or a set of scripts) to periodically update to the > latest development version of each of the projects ... > > > YES. This gets closer to what I want. What I don't like from locking > is that I have to: > Â - know in advance all the projects (+ dependencies) I want to > develop (specially if I'm not the main project developer) > Â - know where they are stored in the disk > Â - do an explicit locking on each of them Haha, and that is why I created the project entries ("load specifications") in the first place:) > > There is a missing abstraction that probably you get in Rowan or tODE > with that project entry specification? Yes, tODE project entries are an implementation that I have been using for several years now and over time I have found some limitations in the tODE implementation that I am attempting to correct in the Rowan implementation ... The Rowan spec I originally referenced[1] is actually "load expression" that is the equivalent of a Gofer load expression ... I have classes for a Metacello-based "load expression" but I haven't gotten to the point where I have integrated Metacello into Rowan. [1] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston > Because the reality is that personally I'm starting a new image every > a couple of days, and having a specification for it would be much > easier than locking here and there... > I want just to specify "My project X at development time requires Y, > Z, H and Z and H are subprojects". > Then, he should realize he should lock Z and H for me. Yes this is exactly the problem I was dealing with in the early implementation of tODE and with project entries. You might want to look again at my FAST talk on "Dangerous Liaisons: Smalltalk, Files, And Git"[2] as I talk about "image clusters" that share a collection of project entries and the fact that each image needs to be able to have a private set of "project entries" ... now that you are experiencing the pain my talk might make more sense:) ... also I am thinking in terms of an "image specification" that is made up of a collection of Rowan "load specifications" ... Rowan has the notion of a Project Set and it is possible to load a set of projects. So it is not that big of a stretch to imagine a .ston image specification (collection load specifications) can be passed around and then customized if needed by individual developers and then project set can be used to create the image or images .... [2] https://www.youtube.com/watch?v=Ejmqs0xLvSk > > Now, If subprojects Z and H are in the same repository as X, that > should not be complicated :). > In Denis' case it could be more complicated... Right but once Denis gets his dependent projects cloned to local disk he can update each of the projects on his schedule by pulling later versions of the projects as he goes ... I lean to disk-based clones that can be shared by multiple images (an "image cluster") ... tODE does not have the notion of image clusters, but I do have sets of images that are sharing a common set of projects where a number of those projects are on development-specific branches so Iknow that this concept makes sense ... > > > To share a specific configuration of development git repos, you > need to know that SHA anyway, so the image can produce a > collection of project entries with the SHA of the commit and those > project entries can be included in a bug report ... > > For Rowan[2], I am using a "load specification"[3], which is a > second generation project entry .... the Rowan work is still > evolving ... > > Anyway, I think that putting the control of what is being used for > development completely in the developers hands and avoiding the > need to edit baselines is a good thing ... and I think that the > idea of having specifications that are shared by a cluster of > images is a good way to go ... > > Dale > > [1] > https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston > <https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston> > [2] https://github.com/dalehenrich/Rowan > <https://github.com/dalehenrich/Rowan> > [3] > https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston > <https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston> > > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

March 6, 2018

[Pharo 7.0-dev] Build #659: 21507-remove-SugsSmalltalkEditorContext

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

There is a new Pharo build available! The status of the build #659 was: SUCCESS. The Pull Request #1036 was integrated: "21507-remove-SugsSmalltalkEditorContext" Pull request url: https://github.com/pharo-project/pharo/pull/1036 Issue Url: https://pharo.fogbugz.com/f/cases/21507 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

[Ann] Commander shortcuts in Settings Browser

by Denis Kudriashov

Hi. With latest version of Commander and Calypso we will have all shortcuts explorable and configurable in Settings Browser: â Currently it uses command class name and class comment for presentation. We can improve it in future if necessary. In addition you can add single shortcut to your own application settings. For example: MyApp class>>appSettingsOn: aBuilder <systemsettings> ann := ClySpawnFullBrowserCommand classAnnotationAt: #browserShortcutActivation. (ann buildSettingNodeOn: aBuilder) label: 'My app shortcut'; description: 'This command opens browser' Shortcut settings are persisted as all other settings. Only redefined shortcuts are stored into the file. This version also allows to add commands into the world menu and world shortcuts. Just use CmdWorldMenuContext for command annotations: CmdOpenFamilyBookCommand class>>worldMenuActivation <classAnnotation> ^CmdContextMenuCommandActivation byRootGroupItemFor: CmdWorldMenuContext CmdOpenFamilyBookCommand class>>globalShortcutActivation <classAnnotation> ^CmdShortcutCommandActivation by: $o meta, $f meta for: CmdWorldMenuContext (CmdOpenFamilyBookCommand is a command from Commander-Examples package). Nice detail: all shortcuts are updated immediately when you modify annotations either from settings or programmatically from browser. Now pull request for Pharo 7 <https://github.com/pharo-project/pharo/pull/1037> is waiting integration. Soon it will be inside. Best regards, Denis

March 6, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #657: 21491 Simplify #testAllButFirstNElements and #testAllButLastNElements

by Marcus Denker

> On 6 Mar 2018, at 16:04, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #657 was: FAILURE. > > The Pull Request #1024 was integrated: "21491 Simplify #testAllButFirstNElements and #testAllButLastNElements" > Pull request url: https://github.com/pharo-project/pharo/pull/1024 > > Issue Url: https://pharo.fogbugz.com/f/cases/21491 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… I restarted the build and it was now green! This actually contains more PRs... 21478 Improve ThreadSafeTranscript isSelfEvaluating (detail / githubweb) 20258 Fix to make recursive links work Add test for 20258 (detail / githubweb) 21483 Cleanup romanNumber and add test (detail / githubweb) 21491 Simplify testAllButFirstNElements, testAllButLastNElements (detail / githubweb) 21501 remove NautilusGroupAutoBuilder (detail / githubweb) 21506 add back two lost inspector extensions (detail / githubweb) for 20258 Fix to make recursive links work: ------------------------------------------ This is work done with Benoit Verhaeghe to finally get meta-links work in deep "recursive" situations. Imagine you want to do something even on methods like #new. But that something for sure will call #new again in the code that you call... With the PR, now a link that calls #new can be installed on Behavior>>#new: link := MetaLink new metaObject: [ Object new ]; level: 0. (Behavior>>#new) ast link: link. ... and it does not lead to a recursion. The "level: 0" means that we are only interested in base-level execution. Every time a link activates, the "level" increases. E.g. if it is put to 1, the link would be active in the meta-level code itself. You can inspect Behavior>>#new and see what kind of code we create at the bytecode level. This is of course slower than just calling a method, so one should only use this mechanism if really needed, and we need to see if this can be optimised. For now this does not take into account any process forking happening on the Meta Level, this needs to be analyzed in the future (past versions just made sure the state is inherited). But that should be a rare case and should make the whole thing more usable already. Marcus

March 6, 2018

[Pharo 7.0-dev] Build #658: 21491 Simplify #testAllButFirstNElements and #testAllButLastNElements

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

There is a new Pharo build available! The status of the build #658 was: SUCCESS. The Pull Request #1024 was integrated: "21491 Simplify #testAllButFirstNElements and #testAllButLastNElements" Pull request url: https://github.com/pharo-project/pharo/pull/1024 Issue Url: https://pharo.fogbugz.com/f/cases/21491 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

So I made pull request for new Calypso version. It modifies #loadCalypso method to fix versions of all dependencies using locking statements. I checked it for Pharo 6. It works fine. https://github.com/pharo-project/pharo/pull/1037 2018-03-05 20:25 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > On 03/05/2018 11:22 AM, Stephane Ducasse wrote: > > In an image where you want to use the dev_pharo7 for a project, you do a > Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the > project ... if there are multiple projects that need to all coordinate > development then you follow the same convention and use a Metacello lock for > each of the projects ... Executing expressions to lock projects is tedious > to use and manage. > > Do you have a text explaining what is a lock? > I do not understand the problems locks solve. > > The "Lock Command Reference" hopefully does the job[1]. > > Dale > > [1] https://github.com/Metacello/metacello/blob/master/docs/ > LockCommandReference.md#lock-command-reference > >

March 6, 2018

[Pharo 7.0-dev] Build #657: 21491 Simplify #testAllButFirstNElements and #testAllButLastNElements

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

There is a new Pharo build available! The status of the build #657 was: FAILURE. The Pull Request #1024 was integrated: "21491 Simplify #testAllButFirstNElements and #testAllButLastNElements" Pull request url: https://github.com/pharo-project/pharo/pull/1024 Issue Url: https://pharo.fogbugz.com/f/cases/21491 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 6, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Guillermo Polito

Hi Dale! On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 03/05/2018 09:07 AM, Guillermo Polito wrote: > >> On the other side, there is the fact that Metacello baselines are so far >> nice to describe release project dependencies, but they are not so nice to >> describe subprojects/development dependencies that may get edited along >> with the parent project. Kind of what we used to do with #bleedingEdge. I >> feel this is a complex problem, that not even SBT or maven that are there >> since years are capable of solving nicely... Tode and Iceberg metacello >> integration try to solve this problem by "ignoring the dependency and using >> the loaded repository" but this may not be successful either... >> > > I have not been following this thread in detail, but this comment leads me > to believe that the issue that you guys are running into has to do with > trying to ongoing distributed development across multiple projects and > multiple platform versions ... I don't know exactly the case of Calypso, but I don't think it is being maintained for other than latest Pharo 7. The Calypso case as I understand it is that it has a couple of dependencies Calypso | - commander | - class annotations The three projects are hosted in different repositories, but Denis wants to work on "bleeding edge" of the three of them at the same time. Then when he loads calypso in a new image, if he just uses a baseline he will load specific versions of the dependencies and not the latest ones... I think this is the particular use case for locking, isn't it? > > If so then I think that the moral equivalent of #bleedingEdge should be a > branch structure along the lines of: > > master branch --- the project release that is known to work on all > supported platform versions. > dev_pharo6 --- the current #bleedingEdge for Pharo6.0 > dev_pharo7 --- the current #bleedingEdge for Pharo7.0 > > In an image where you want to use the dev_pharo7 for a project, you do a > Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the > project ... if there are multiple projects that need to all coordinate > development then you follow the same convention and use a Metacello lock > for each of the projects ... Executing expressions to lock projects is > tedious to use and manage. > It is not that complicated I think ^^. > > In tODE I started using project entries[1] that are downloaded to disk and > shared by multiple images that allow a developer to specify what > branch/tag/commit they are interested in using ... each image that is > started up in a "cluster" uses the project entry to do a Metacello lock on > the project "automagically"... if there is a series of projects where the > developer needs to use dev_pharo6 they can arrange to edit the project > entry to reflect the proper branches for the set of projects that need > special _development_ treatment ... these .ston files can be shared amongst > groups of developers ... of course once the local clones of these projects > are on the local disk, then it is up to the developer (or a set of scripts) > to periodically update to the latest development version of each of the > projects ... YES. This gets closer to what I want. What I don't like from locking is that I have to: - know in advance all the projects (+ dependencies) I want to develop (specially if I'm not the main project developer) - know where they are stored in the disk - do an explicit locking on each of them There is a missing abstraction that probably you get in Rowan or tODE with that project entry specification? Because the reality is that personally I'm starting a new image every a couple of days, and having a specification for it would be much easier than locking here and there... I want just to specify "My project X at development time requires Y, Z, H and Z and H are subprojects". Then, he should realize he should lock Z and H for me. Now, If subprojects Z and H are in the same repository as X, that should not be complicated :). In Denis' case it could be more complicated... > To share a specific configuration of development git repos, you need to > know that SHA anyway, so the image can produce a collection of project > entries with the SHA of the commit and those project entries can be > included in a bug report ... > > For Rowan[2], I am using a "load specification"[3], which is a second > generation project entry .... the Rowan work is still evolving ... > > Anyway, I think that putting the control of what is being used for > development completely in the developers hands and avoiding the need to > edit baselines is a good thing ... and I think that the idea of having > specifications that are shared by a cluster of images is a good way to go > ... > > Dale > > [1] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston > [2] https://github.com/dalehenrich/Rowan > [3] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 6, 2018

Re: [Pharo-dev] Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by Henrik Sperre Johansen

Seems to me aioEnable somehow triggers this. It maintains buffers of size FD_SETSIZE (1024 on Linux)*, so an fd parameter** >= that, could probably trigger such an error. Maybe you could put a halt in whichever method in OSSubprocess/OSProcess calls the primitive triggered when condition occurs, to see if that is the cause? If so, identifying *why* you end up with fd's that high (which, afaik, isn't normal), will probably lead to a workaround/solution... Cheers, Henry * https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c7b37bbc12cd8730… ** https://github.com/pharo-project/pharo-vm/blob/c50dec02d2875de56c84d11889c7… -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 6, 2018

Re: [Pharo-dev] Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by Thierry Goubier

Hi Sabine, have you tried with a 64bits version of Pharo (with a recent VM, i.e. newer than the 6.1 vm)? I use the 5.0-201801170946, for example. If, by chance, you manage to create a script provoking the segfault, that may really help. Thierry 2018-03-06 11:49 GMT+01:00 Sabine Manaa <manaa.sabine(a)gmail.com>: > Hi, > > I can report the following: > > The problem with the Buffer overflow remains also with OSProcess. > Also with the normal vm (https://get.pharo.org ). > > Summary: I have buffer overflow crashes with my application on Linux. > The same code runs without problems on MacOS and on Windows. > I have the same test data/database and do exactly the same. > > The problem occurs only after calling several times OSProcess/OSSubprocess. > This is the reason why I first had a suspicion that OSSubprocess is > responsible for the crashes. > > Can anyone tell me how to proceed to find the reason for the buffer > overflow? > There is no PharoDebug.log > > Help is very appreciated! > > This is the message when terminating: > > root@Pharo_ubuntu_16:/spf/build# ./pharo Pharo-Productive-SPF.image > --no-quit > > SmalltalkImageInstanceID class>>startUp*** buffer overflow detected ***: > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated > > ======= Backtrace: ========= > > /lib/i386-linux-gnu/libc.so.6(+0x67377)[0xf75b9377] > > /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x68)[0xf7649708] > > /lib/i386-linux-gnu/libc.so.6(+0xf58f8)[0xf76478f8] > > /lib/i386-linux-gnu/libc.so.6(+0xf75fa)[0xf76495fa] > > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo(aioEnable+0x31)[0x80c9811] > > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x81215ee] > > [0x90010e0] > > [0x90ad2d0] > > [0x90db8b4] > > [0x90ad24a] > > [0x900be6b] > > [0x900b04d] > > [0x9007a3e] > > [0x9004247] > > [0x9004572] > > [0x9001020] > > [0xa98c524] > > [0xb1755db] > > [0x9003efc] > > [0x9001020] > > [0xdcb558c] > > [0xb0d4d95] > > [0x9000ff0] > > ======= Memory map: ======== > > 08048000-08164000 r-xp 00000000 00:1b 1183256 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo > > 08164000-08165000 r--p 0011b000 00:1b 1183256 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo > > 08165000-08170000 rw-p 0011c000 00:1b 1183256 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo > > 08170000-081a7000 rw-p 00000000 00:00 0 > > 08fdd000-08ffe000 rw-p 00000000 00:00 0 > [heap] > > 09000000-09100000 rwxp 00000000 00:00 0 > > 09100000-11200000 rw-p 00000000 00:00 0 > > f552e000-f554a000 r-xp 00000000 00:1b 8244 > /lib/i386-linux-gnu/libgcc_s.so.1 > > f554a000-f554b000 rw-p 0001b000 00:1b 8244 > /lib/i386-linux-gnu/libgcc_s.so.1 > > f554b000-f684c000 rw-p 00000000 00:00 0 > > f684c000-f684f000 r-xp 00000000 00:1b 1183242 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so > > f684f000-f6850000 r--p 00002000 00:1b 1183242 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so > > f6850000-f6851000 rw-p 00003000 00:1b 1183242 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/JPEGReaderPlugin.so > > f6851000-f68b2000 r-xp 00000000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b2000-f68b3000 ---p 00061000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b3000-f68b5000 r--p 00061000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b5000-f68b9000 rw-p 00063000 00:1b 1183230 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libssl.so.1.0.0 > > f68b9000-f6a7b000 r-xp 00000000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a7b000-f6a7c000 ---p 001c2000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a7c000-f6a8c000 r--p 001c2000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a8c000-f6a93000 rw-p 001d2000 00:1b 1183239 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 > > f6a93000-f6a96000 rw-p 00000000 00:00 0 > > f6a96000-f6a9b000 r-xp 00000000 00:1b 1183249 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so > > f6a9b000-f6a9c000 r--p 00004000 00:1b 1183249 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so > > f6a9c000-f6a9d000 rw-p 00005000 00:1b 1183249 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/SqueakSSL.so > > f6a9d000-f6ab1000 r-xp 00000000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab1000-f6ab2000 ---p 00014000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab2000-f6ab3000 r--p 00014000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab3000-f6ab4000 rw-p 00015000 00:1b 7925 > /lib/i386-linux-gnu/libresolv-2.23.so > > f6ab4000-f6ab6000 rw-p 00000000 00:00 0 > > f6ab6000-f6abb000 r-xp 00000000 00:1b 7931 > /lib/i386-linux-gnu/libnss_dns-2.23.so > > f6abb000-f6abc000 r--p 00004000 00:1b 7931 > /lib/i386-linux-gnu/libnss_dns-2.23.so > > f6abc000-f6abd000 rw-p 00005000 00:1b 7931 > /lib/i386-linux-gnu/libnss_dns-2.23.so > > f6abd000-f6c05000 rw-p 00000000 00:00 0 > > f6c05000-f6c2e000 r-xp 00000000 00:1b 8373 > /lib/i386-linux-gnu/libpng12.so.0.54.0 > > f6c2e000-f6c2f000 r--p 00028000 00:1b 8373 > /lib/i386-linux-gnu/libpng12.so.0.54.0 > > f6c2f000-f6c30000 rw-p 00029000 00:1b 8373 > /lib/i386-linux-gnu/libpng12.so.0.54.0 > > f6c30000-f6c49000 r-xp 00000000 00:1b 8362 > /lib/i386-linux-gnu/libz.so.1.2.8 > > f6c49000-f6c4a000 r--p 00018000 00:1b 8362 > /lib/i386-linux-gnu/libz.so.1.2.8 > > f6c4a000-f6c4b000 rw-p 00019000 00:1b 8362 > /lib/i386-linux-gnu/libz.so.1.2.8 > > f6c4b000-f6cf6000 r-xp 00000000 00:1b 8395 > /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 > > f6cf6000-f6cfa000 r--p 000aa000 00:1b 8395 > /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 > > f6cfa000-f6cfb000 rw-p 000ae000 00:1b 8395 > /usr/lib/i386-linux-gnu/libfreetype.so.6.12.1 > > f6cfb000-f6d02000 r-xp 00000000 00:1b 1183229 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so > > f6d02000-f6d03000 r--p 00006000 00:1b 1183229 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so > > f6d03000-f6d04000 rw-p 00007000 00:1b 1183229 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so > > f6d04000-f6d0f000 r-xp 00000000 00:1b 7934 > /lib/i386-linux-gnu/libnss_files-2.23.so > > f6d0f000-f6d10000 r--p 0000a000 00:1b 7934 > /lib/i386-linux-gnu/libnss_files-2.23.so > > f6d10000-f6d11000 rw-p 0000b000 00:1b 7934 > /lib/i386-linux-gnu/libnss_files-2.23.so > > f6d11000-f6d38000 rw-p 00000000 00:00 0 > > f6d38000-f6d39000 ---p 00000000 00:00 0 > > f6d39000-f7539000 rw-p 00000000 00:00 0 > [stack:21188] > > f7539000-f753b000 r-xp 00000000 00:1b 7968 > /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so > > f753b000-f753c000 r--p 00001000 00:1b 7968 > /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so > > f753c000-f753d000 rw-p 00002000 00:1b 7968 > /usr/lib/i386-linux-gnu/gconv/MACINTOSH.so > > f753d000-f7544000 r--s 00000000 00:1b 7977 > /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache > > f7544000-f754a000 r-xp 00000000 00:1b 1183240 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so > > f754a000-f754b000 r--p 00005000 00:1b 1183240 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so > > f754b000-f754c000 rw-p 00006000 00:1b 1183240 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-sound-OSS.so > > f754c000-f754e000 r-xp 00000000 00:1b 1183257 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so > > f754e000-f754f000 r--p 00001000 00:1b 1183257 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so > > f754f000-f7550000 rw-p 00002000 00:1b 1183257 > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/vm-display-null.so > > f7550000-f7552000 rw-p 00000000 00:00 0 > > f7552000-f7702000 r-xp 00000000 00:1b 7921 > /lib/i386-linux-gnu/libc-2.23.so > > f7702000-f7704000 r--p 001af000 00:1b 7921 > /lib/i386-linux-gnu/libc-2.23.so > > f7704000-f7705000 rw-p 001b1000 00:1b 7921 > /lib/i386-linux-gnu/libc-2.23.so > > f7705000-f7708000 rw-p 00000000 00:00 0 > > f7708000-f775b000 r-xp 00000000 00:1b 7917 > /lib/i386-linux-gnu/libm-2.23.so > > f775b000-f775c000 r--p 00052000 00:1b 7917 > /lib/i386-linux-gnu/libm-2.23.so > > f775c000-f775d000 rw-p 00053000 00:1b 7917 > /lib/i386-linux-gnu/libm-2.23.so > > f775d000-f7776000 r-xp 00000000 00:1b 7920 > /lib/i386-linux-gnu/libpthread-2.23.so > > f7776000-f7777000 r--p 00018000 00:1b 7920 > /lib/i386-linux-gnu/libpthread-2.23.so > > f7777000-f7778000 rw-p 00019000 00:1b 7920 > /lib/i386-linux-gnu/libpthread-2.23.so > > f7778000-f777a000 rw-p 00000000 00:00 0 > > f777a000-f777d000 r-xp 00000000 00:1b 7923 > /lib/i386-linux-gnu/libdl-2.23.so > > f777d000-f777e000 r--p 00002000 00:1b 7923 > /lib/i386-linux-gnu/libdl-2.23.so > > f777e000-f777f000 rw-p 00003000 00:1b 7923 > /lib/i386-linux-gnu/libdl-2.23.so > > f777f000-f7780000 rw-p 00000000 00:00 0 > > f7780000-f7781000 r-xp 00000000 00:00 0 > [vdso] > > f7781000-f77a4000 r-xp 00000000 00:1b 7919 > /lib/i386-linux-gnu/ld-2.23.so > > f77a4000-f77a5000 r--p 00022000 00:1b 7919 > /lib/i386-linux-gnu/ld-2.23.so > > f77a5000-f77a6000 rw-p 00023000 00:1b 7919 > /lib/i386-linux-gnu/ld-2.23.so > > ffc55000-ffcd1000 rw-p 00000000 00:00 0 > [stack] > > ./pharo: line 11: 14639 Aborted "$DIR"/"pharo-vm/pharo" > --nodisplay "$@" > > > > 2018-03-05 17:38 GMT+01:00 Sabine Manaa <manaa.sabine(a)gmail.com>: >> >> Hi Mariano and Thierry, >> >> I load on Pharo 32 bit with: >> >> spec >> baseline: 'OSSubprocess' >> with: [ spec >> className: 'BaselineOfOSSubprocess'; >> repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ]; >> import: 'OSSubprocess' >> >> Tomorrow I will try to load on Pharo7 and try to use OSProcess and see if >> it still crashes. >> >> Sabine >> >> >> >> >> >> 2018-03-05 17:23 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>> Hi Sabine, >>> >>> Which OSSubprocess version are you using? If are using ConfigurationOf to >>> load it, then please tell me which version from there. >>> If you are using from baseline, tell me if you are grabbing master, a >>> given tag , a given commit, etc. >>> I will assume it is Pharo 32 bits rigth? >>> >>> I will continue with a more detailed answer once you get back to me with >>> above questions. >>> >>> Cheers, >>> >>> >>> >>> >>> On Mon, Mar 5, 2018 at 1:14 PM, Sabine Manaa <manaa.sabine(a)gmail.com> >>> wrote: >>>> >>>> Hi Alistair, >>>> >>>> thank you! The message (pthread_setschedparam failed: Operation not >>>> permitted) is gone now. So Question 1 is solved. >>>> >>>> But the crashes (Question 2) are remaining. After calling several >>>> OSSubprocess commands, Pharo crashes without PharoDebug.log. >>>> >>>> Anyone having an Idea what I could do? >>>> >>>> Sabine >>>> >>>> >>>> >>>> >>>> 2018-03-05 13:07 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >>>>> >>>>> Hi Sabine, >>>>> >>>>> The docket container will need to be privileged to adjust thread >>>>> priority. >>>>> >>>>> >>>>> Cheers, >>>>> Alistair >>>>> (on phone) >>>>> >>>>> On 5 Mar. 2018 12:44, "Sabine Manaa" <manaa.sabine(a)gmail.com> wrote: >>>>> >>>>> We want to run Pharo6 with Ubuntu 16.04 Linux (in a Docker Image) and >>>>> use >>>>> OSSubprocess. >>>>> >>>>> For this, we use this vm: https://get.pharo.org/61+vmT >>>>> >>>>> [1] tells me: "If you are installing under Linux, then you must use a >>>>> threaded heartbeat VM" >>>>> >>>>> We also created a file /etc/security/limits.d/pharo.conf and put the >>>>> parameters in like described in the message [2] when startup. Also we >>>>> log >>>>> out and in. >>>>> >>>>> Question 1: the message (pthread_setschedparam failed: Operation not >>>>> permitted) comes again to the console each time we use OSSubprocess. As >>>>> far >>>>> as I understand, it should disappear. Does this mean, that we did not >>>>> edit >>>>> the pharo.conf correctly? >>>>> >>>>> Question 2: after several uses of OSSubprocess within our application, >>>>> Pharo >>>>> crashes (no PharoDebug.log) with the following messages [3]. >>>>> How can we avoid this, what are we doing wrong? >>>>> >>>>> Question 3: sometimes (!) when we load (exactly the same code loaded >>>>> with a >>>>> script), we also get a crash, see [4]. Bug? wrong vm? >>>>> >>>>> I am unhappy with this and it takes a lot of time. What are we doing >>>>> wrong? >>>>> We want to run Pharo6 with OSSubprocess in Linux within a docker image >>>>> for >>>>> our staging environment. >>>>> >>>>> Help very welcome :-) >>>>> Sabine >>>>> >>>>> >>>>> [1]https://github.com/marianopeck/OSSubprocess >>>>> >>>>> [2](https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#lin… >>>>> >>>>> [3]crash message >>>>> *** buffer overflow detected ***: >>>>> /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated >>>>> ======= Backtrace: ========= >>>>> /lib/i386-linux-gnu/libc.so.6(+0x67377)[0xf75f3377] >>>>> /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x68)[0xf7683708] >>>>> /lib/i386-linux-gnu/libc.so.6(+0xf58f8)[0xf76818f8] >>>>> /lib/i386-linux-gnu/libc.so.6(+0xf75fa)[0xf76835fa] >>>>> >>>>> /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo(aioEnable+0x31)[0x80c9811] >>>>> /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x81215ee] >>>>> [0xa1010e0] >>>>> [0xa1c2bb8] >>>>> [0xa15f50c] >>>>> ....a lot more >>>>> >>>>> >>>>> >>>>> [4] PharoDebug.log >>>>> HERE_BE_DRAGONS_HERE >>>>> KeyNotFound: key #arg1 not found in Dictionary >>>>> 5 March 2018 11:31:51.792142 am >>>>> >>>>> VM: unix - i686 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2254 >>>>> uuid: >>>>> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >>>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >>>>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >>>>> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >>>>> $ >>>>> Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>>>> >>>>> Image: Pharo6.0 [Latest update: #60536] >>>>> >>>>> Dictionary>>errorKeyNotFound: >>>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>>> Arguments and temporary variables: >>>>> aKey: #arg1 >>>>> Receiver's instance variables: >>>>> tally: 2 >>>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>>> >>>>> >>>>> [ self errorKeyNotFound: key ] in Dictionary>>at: >>>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>>> Arguments and temporary variables: >>>>> key: #arg1 >>>>> Receiver's instance variables: >>>>> tally: 2 >>>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>>> >>>>> >>>>> Dictionary>>at:ifAbsent: >>>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>>> Arguments and temporary variables: >>>>> arg1: #arg1 >>>>> arg2: [ self errorKeyNotFound: key ] >>>>> tmp1: nil >>>>> Receiver's instance variables: >>>>> tally: 2 >>>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>>> >>>>> >>>>> Dictionary>>at: >>>>> Receiver: a Dictionary(#arg3->1 #tmp2->2 ) >>>>> Arguments and temporary variables: >>>>> key: #arg1 >>>>> Receiver's instance variables: >>>>> tally: 2 >>>>> array: {nil. nil. #arg3->1. #tmp2->2. nil} >>>>> >>>>> >>>>> IRPushClosureCopy>>indexForVarNamed: >>>>> Receiver: pushClosureCopyCopiedValues: #() args: #(#arg3) >>>>> Arguments and temporary variables: >>>>> aName: #arg1 >>>>> Receiver's instance variables: >>>>> sourceNode: RBBlockNode([ :arg3 | >>>>> | tmp2 | >>>>> tmp2 := arg3. >>>>> tmp2 >>>>> nextPutAll: arg...etc... >>>>> bytecodeIndex: nil >>>>> sequence: an IRSequence (1) >>>>> destination: an IRSequence (3) >>>>> successor: nil >>>>> numArgs: nil >>>>> blockSequence: an IRSequence (2) >>>>> tempMap: a Dictionary(#arg3->1 #tmp2->2 ) >>>>> copiedValues: #() >>>>> lastBlockSequence: an IRSequence (2) >>>>> arguments: #(#arg3) >>>>> >>>>> >>>>> IRTranslatorV2>>visitPushTemp: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> tmp: pushTemp: #arg1 >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRPushTemp>>accept: >>>>> Receiver: pushTemp: #arg1 >>>>> Arguments and temporary variables: >>>>> aVisitor: an IRTranslatorV2 >>>>> Receiver's instance variables: >>>>> sourceNode: RBArgumentNode(arg1) >>>>> bytecodeIndex: nil >>>>> sequence: an IRSequence (2) >>>>> name: #arg1 >>>>> >>>>> >>>>> IRTranslatorV2(IRVisitor)>>visitNode: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> elem: pushTemp: #arg1 >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRTranslatorV2>>visitInstruction: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> instr: pushTemp: #arg1 >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> [ :arg2 | self visitInstruction: arg2 ] in >>>>> IRTranslatorV2(IRVisitor)>>visitSequence: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> arg1: an IRSequence (2) >>>>> arg2: pushTemp: #arg1 >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> OrderedCollection>>do: >>>>> Receiver: an OrderedCollection(pushTemp: #arg3 popIntoTemp: >>>>> #tmp2 pushTemp: >>>>> #tmp2 pushDup pushTemp: ...etc... >>>>> Arguments and temporary variables: >>>>> <<error during printing> >>>>> Receiver's instance variables: >>>>> array: an Array(pushTemp: #arg3 popIntoTemp: #tmp2 >>>>> pushTemp: #tmp2 >>>>> pushDup push...etc... >>>>> firstIndex: 1 >>>>> lastIndex: 25 >>>>> >>>>> >>>>> IRSequence>>do: >>>>> Receiver: an IRSequence (2) >>>>> Arguments and temporary variables: >>>>> aBlock: [ :arg2 | self visitInstruction: arg2 ] >>>>> Receiver's instance variables: >>>>> sequence: an OrderedCollection(pushTemp: #arg3 >>>>> popIntoTemp: #tmp2 >>>>> pushTemp: #tm...etc... >>>>> orderNumber: 2 >>>>> method: an IRMethod >>>>> >>>>> >>>>> IRTranslatorV2(IRVisitor)>>visitSequence: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> arg1: an IRSequence (2) >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRTranslatorV2>>visitSequence: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> instructionSequence: an IRSequence (2) >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRSequence>>accept: >>>>> Receiver: an IRSequence (2) >>>>> Arguments and temporary variables: >>>>> aVisitor: an IRTranslatorV2 >>>>> Receiver's instance variables: >>>>> sequence: an OrderedCollection(pushTemp: #arg3 >>>>> popIntoTemp: #tmp2 >>>>> pushTemp: #tm...etc... >>>>> orderNumber: 2 >>>>> method: an IRMethod >>>>> >>>>> >>>>> IRTranslatorV2(IRVisitor)>>visitNode: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> elem: an IRSequence (2) >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> [ :arg2 | self visitNode: arg2 ] in >>>>> IRTranslatorV2(IRVisitor)>>visitNodes: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> arg1: a SortedCollection(an IRSequence (1) an >>>>> IRSequence (2) an >>>>> IRSequence (3) ...etc... >>>>> arg2: an IRSequence (2) >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> SortedCollection(OrderedCollection)>>do: >>>>> Receiver: a SortedCollection(an IRSequence (1) an IRSequence >>>>> (2) an >>>>> IRSequence (3) an IRSequence (4)...etc... >>>>> Arguments and temporary variables: >>>>> <<error during printing> >>>>> Receiver's instance variables: >>>>> array: an Array(an IRSequence (1) an IRSequence (2) an >>>>> IRSequence (3) an >>>>> IRSequ...etc... >>>>> firstIndex: 1 >>>>> lastIndex: 7 >>>>> sortBlock: [ :arg2 :arg3 | arg2 orderNumber <= >>>>> arg3 orderNumber ] >>>>> >>>>> >>>>> IRTranslatorV2(IRVisitor)>>visitNodes: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> arg1: a SortedCollection(an IRSequence (1) an >>>>> IRSequence (2) an >>>>> IRSequence (3) ...etc... >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRTranslatorV2>>visitSequences: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> arg1: a SortedCollection(an IRSequence (1) an >>>>> IRSequence (2) an >>>>> IRSequence (3) ...etc... >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRTranslatorV2>>visitMethod: >>>>> Receiver: an IRTranslatorV2 >>>>> Arguments and temporary variables: >>>>> anIr: an IRMethod >>>>> Receiver's instance variables: >>>>> gen: an IRBytecodeGenerator >>>>> currentScope: a Stack(pushClosureCopyCopiedValues: >>>>> #() args: #(#arg3) an >>>>> IRMeth...etc... >>>>> trailer: a CompiledMethodTrailer >>>>> tempVectorStack: a Stack() >>>>> compilationContext: a CompilationContext >>>>> >>>>> >>>>> IRMethod>>accept: >>>>> Receiver: an IRMethod >>>>> Arguments and temporary variables: >>>>> aVisitor: an IRTranslatorV2 >>>>> Receiver's instance variables: >>>>> sourceNode: logError: arg1 inContext: arg2 >>>>> self >>>>> logStdErrorDuring: [ :arg3 |...etc... >>>>> startSequence: an IRSequence (1) >>>>> numArgs: 2 >>>>> properties: nil >>>>> tempMap: a Dictionary(#arg1->1 #arg2->2 ) >>>>> pragmas: an OrderedCollection() >>>>> additionalLiterals: an OCLiteralSet(#ifNotNil:) >>>>> compiledMethod: nil >>>>> compilationContext: a CompilationContext >>>>> irPrimitive: primitive 0 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: >>>>> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >> >

March 6, 2018