[Pharo-dev] Pharo image don't restart

[Trussardi Dario Romano]

Ciao,	i have a Ubuntu system		   where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher.	I work with it for a month and all work fine.	Now after a save the image the system begin unstabled.	When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down.	The first time i can launch the same image from the PharoLauncher,		but after a new  image  save ( the image go down ) i can't relaunch the image.	When i do the launch the pharoLauch shell report:no room in eden for allocateSmallNewSpaceSlots:format:classIndex:

/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo
Pharo VM version: 5.0-201806281256  Thu Jun 28 13:04:44 UTC 2018 gcc 4.8 
[Production Spur 64-bit VM]
Built from: CoInterpreter VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
Revision: VM: 201806281256 .
Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1
Plugins: 201806281256 ..
Build host: Linux travis-job-46342785-b1c1-4811-8c3c-9b2a88ae7ecc 
4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
plugin path:  [default: 
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/]


C stack backtrace & registers:
*/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x41b165]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo(error+0xf)[0x41c87f]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x432b1c]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x43f52d]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x44838f]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae1]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/7

Re: [Pharo-dev] Application entrypoints

[nanqueti]

we could also use the "script:" annotation, and the system browser
could show it at the class level (it already shows at the method level)

nicolas

On Thu, 2018-12-13 at 10:40 +0800, Ben Coman wrote:
> A question was asked on discord... "I know how to start the lights
> out example, 
> and feed my objects test data with the testing framework, but how
> does one start 
> something like ChineseCheckers? How does one find the entry point? 
> Is there a convention on naming a starting place?"
> 
> I remember having similar thoughts when starting in Pharo.
> 
> One convention I have seen is that amongst all the classes presumably
> prefixed "CC"
> one class would stand out being named for the application without the
> prefix. 
> e.g. class "ChineseCheckers".  That is only a narrow chance for a
> namespace conflict,
> the the risk still remains.
> 
> I suggested another path would have a package tag "Application" 
> (i.e. "ChineseCheckers-Application") that contains a single class 
> which has an #open method on the class-side.
> The tag "Application" sorts high up on the package-tags and is self-
> descriptive.
> But I've not seen that used before, so while I think its a good idea,
> its not really a convention. 
> Conventions are only useful if they are broadly understood.
> 
> So I'm wondering what other things people do to draw attention to
> their application entry points.  
> 
> cheers -ben
-- 
Nicolas Anquetil
RMod team -- Inria Lille

Re: [Pharo-dev] Pharo image don't restart

[Ben Coman]

You don't mention that you rebooted, so just try that first.

cheers -ben

P.S. Quick summary for others, the error is...
"no room in eden for allocateSmallNewSpaceSlots:format:classIndex:"

Top of Smalltalk stack dump:
0x7ffeec4c4a88 I ExternalSemaphoreTable class>unprotectedExternalObjects:
0x1d044b0: a(n) ExternalSemaphoreTable class
0x7ffeec4c4ad0 I [] in ExternalSemaphoreTable class>clearExternalObjects
0x1d044b0: a(n) ExternalSemaphoreTable class
0x7ffeec4c4b20 I [] in Semaphore>critical: 0x211ec80: a(n) Semaphore
0x7ffeec4c4b70 I BlockClosure>ensure: 0x165e2d0: a(n) BlockClosure
0x7ffeec4c4bc0 I Semaphore>critical: 0x211ec80: a(n) Semaphore
0x7ffeec4c4c08 I ExternalSemaphoreTable class>clearExternalObjects
0x1d044b0: a(n) ExternalSemaphoreTable class
0x7ffeec4c4c48 I SmalltalkImage>clearExternalObjects 0x1d0a920: a(n)
SmalltalkImage
0x7ffeec4c4c88 I WorkingSession>start: 0x165e000: a(n) WorkingSession
0x7ffeec4c4ce0 I SessionManager>launchSnapshot:andQuit: 0x1d70a10: a(n)
SessionManager
0xbff6c50 s SessionManager>snapshot:andQuit:
0xc006a18 s [] in SmalltalkImage>snapshot:andQuit:



On Thu, 13 Dec 2018 at 16:26, Trussardi Dario Romano <
dario.trussa...@tiscali.it> wrote:

>
>
>
>
>
>
>
> *Ciao, i have a Ubuntu system   where i defined a Pharo 7.0 - 64bit image
> managed with PharoLauncher. I work with it for a month and all work fine.
> Now after a save the image the system begin unstabled. When the mouse go on
> the windows summary bar ( at the bottom of the Pharo window ) the image go
> down. The first time i can launch the same image from the PharoLauncher,
> but after a new  image save ( the image go down ) i can't relaunch the
> image. When i do the launch the pharoLauch shell report:*
>
>
>
>
>
>
> * I have some important work in the image ( and i don't have a backup )
> Some consideration? Thanks, Dario*
>

Re: [Pharo-dev] Pharo image don't restart

[Trussardi Dario Romano]

Ciao,


> You don't mention that you rebooted, so just try that first.  

sorry but I do not understand what you mean.

In any case i rebooted the system.  ( restart )

The PharoLauncher   launch command on the   Pharo 7.0 
-64development image  report the same error.

Thanks,

Dario
> 
> cheers -ben
> 
> P.S. Quick summary for others, the error is...
> "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:"
> 
> Top of Smalltalk stack dump:  
> 0x7ffeec4c4a88 I ExternalSemaphoreTable class>unprotectedExternalObjects: 
> 0x1d044b0: a(n) ExternalSemaphoreTable class
> 0x7ffeec4c4ad0 I [] in ExternalSemaphoreTable class>clearExternalObjects 
> 0x1d044b0: a(n) ExternalSemaphoreTable class
> 0x7ffeec4c4b20 I [] in Semaphore>critical: 0x211ec80: a(n) Semaphore
> 0x7ffeec4c4b70 I BlockClosure>ensure: 0x165e2d0: a(n) BlockClosure
> 0x7ffeec4c4bc0 I Semaphore>critical: 0x211ec80: a(n) Semaphore
> 0x7ffeec4c4c08 I ExternalSemaphoreTable class>clearExternalObjects 0x1d044b0: 
> a(n) ExternalSemaphoreTable class
> 0x7ffeec4c4c48 I SmalltalkImage>clearExternalObjects 0x1d0a920: a(n) 
> SmalltalkImage
> 0x7ffeec4c4c88 I WorkingSession>start: 0x165e000: a(n) WorkingSession
> 0x7ffeec4c4ce0 I SessionManager>launchSnapshot:andQuit: 0x1d70a10: a(n) 
> SessionManager 
>   0xbff6c50 s SessionManager>snapshot:andQuit: 
>   0xc006a18 s [] in SmalltalkImage>snapshot:andQuit:
> 
> 
> 
> On Thu, 13 Dec 2018 at 16:26, Trussardi Dario Romano 
>  wrote:
> Ciao,
> 
>   i have a Ubuntu system
>  where i defined a Pharo 7.0 - 64bit image managed with 
> PharoLauncher.
> 
>   I work with it for a month and all work fine.
> 
>   Now after a save the image the system begin unstabled.
> 
>   When the mouse go on the windows summary bar ( at the bottom of the 
> Pharo window ) the image go down.
> 
>   The first time i can launch the same image from the PharoLauncher,
> 
>   but after a new  image  save ( the image go down ) i can't 
> relaunch the image.
> 
>   When i do the launch the pharoLauch shell report:
> 
> 
>   I have some important work in the image ( and i don't have a backup )
> 
>   Some consideration?
> 
>   Thanks,
>   Dario
> 

Re: [Pharo-dev] Pharo image don't restart

[Ben Coman]

On Thu, 13 Dec 2018 at 18:04, Trussardi Dario Romano <
dario.trussa...@tiscali.it> wrote:

> Ciao,
>
> You don't mention that you rebooted, so just try that first.
>
>
> sorry but I do not understand what you mean.
>
> In any case i rebooted the system. ( restart )
>

Yes, thats what I meant.  Always the easiest thing to try.


>
> The PharoLauncher  launch command on the Pharo 7.0 -64development image  
> report
> the same error.
>
>
>> * I have some important work in the image ( and i don't have a backup )
>> Some consideration?*
>>
>
 I'm not in a position to diagnose the error, but perhaps help you recover
your work.
In PharoLauncher, if you right-click on the image you are trying to launch,
then choose "Show in folder" then browse to "pharo-local/ombu-sessions"
and you should see some files.  If you create a fresh image and copy those
to the same location there,
the go World menu > Tools > Code Changes and see if you find your work.
Check out the filters. Possibly useful...
* Show only latest changes
* Show only changes in this package

HTH
cheers -ben

Re: [Pharo-dev] periodic auto actions on bug tracker

[Marcus Denker]

> On 13 Dec 2018, at 03:35, Sean P. DeNigris  wrote:
> 
> Marcus Denker-4 wrote
>>> I support the auto-closing of old tickets to avoid bug bankruptcy
>> ...
>> Yes, that is a good idea. 
> 
> I thought we already did that. Don't we even have a stale/timeout tag to
> distinguish from other reasons for closing and help find them again later if
> needed?
> 

We close them with a timeout tag. 

But we do not send a public mail “hey, these tickets will be closed next week”.

Only the *owner* gets a message on closing.

Marcus

Re: [Pharo-dev] Pharo image don't restart

[Trussardi Dario Romano]

Ciao,

> Ciao,
>> You don't mention that you rebooted, so just try that first.  
> 
>   sorry but I do not understand what you mean.
> 
>   In any case i rebooted the system.  ( restart )
> 
> Yes, thats what I meant.  Always the easiest thing to try.
>  
> 
>   The PharoLauncher   launch command on the   Pharo 7.0 
> -64development image  report the same error.
>>  I have some important work in the image ( and i don't have a backup )
>> 
>>  Some consideration?
> 
> 
>  I'm not in a position to diagnose the error, but perhaps help you recover 
> your work.

Can someone help me?

It's very important.!!!

> In PharoLauncher, if you right-click on the image you are trying to launch,
> then choose "Show in folder" then browse to "pharo-local/ombu-sessions"
> and you should see some files.  If you create a fresh image and copy those to 
> the same location there,
> the go World menu > Tools > Code Changes and see if you find your work.
> Check out the filters. Possibly useful...
> * Show only latest changes
> * Show only changes in this package

Thanks.

OK, i see the methods . ( i need to understand what i can 
do with these .  )

But in the image i  have the  data base with real data.. and ..

Stupidly I lost the version that started with the launcher,

saving it on itself after it began to have problems..


Thanks,

Dario 

[Pharo-dev] [Pharo 7.0] Build #35: 22763 Tag classes in Text-Diff package

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #35 was: SUCCESS.

The Pull Request #2067 was integrated: "22763 Tag classes in Text-Diff package"
Pull request url: https://github.com/pharo-project/pharo/pull/2067

Issue Url: https://pharo.fogbugz.com/f/cases/22763
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/35/

Re: [Pharo-dev] Pharo image don't restart

[Christophe Demarey]

Hi,

The problem seems to come from: "no room in eden for 
allocateSmallNewSpaceSlots:format:classIndex:"
Eden is a part of the heap where new objects are allocated.
Basically, it appears that Pharo cannot create objects any more.
You can get information about gc and eden space here: 
https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
 


Could you try to run your image in headless mode to see if it starts?
ex: 

I would try to start your image with a bigger size for the eden.
Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
parameterAt: 44) * 4.
but it means you need an image that is started …

You can also set it as an argument to the VM: --eden [mk]

You could try with —eden 15207744 for example:
~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ version\)/Pharo\ 
7.0\ -\ 64bit\ \(development\ version\).image 

Regards,
Christophe


> Le 13 déc. 2018 à 09:25, Trussardi Dario Romano  
> a écrit :
> 
> Ciao,
> 
>   i have a Ubuntu system
>  where i defined a Pharo 7.0 - 64bit image managed with 
> PharoLauncher.
> 
>   I work with it for a month and all work fine.
> 
>   Now after a save the image the system begin unstabled.
> 
>   When the mouse go on the windows summary bar ( at the bottom of the 
> Pharo window ) the image go down.
> 
>   The first time i can launch the same image from the PharoLauncher,
> 
>   but after a new  image  save ( the image go down ) i can't 
> relaunch the image.
> 
>   When i do the launch the pharoLauch shell report:
> 
> 
> 
>   I have some important work in the image ( and i don't have a backup )
> 
>   Some consideration?
> 
>   Thanks,
>   Dario
> 

[Pharo-dev] [Pharo 7.0] Build #36: 22762 Cleanup TextEditorTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #36 was: FAILURE.

The Pull Request #2066 was integrated: "22762 Cleanup TextEditorTest"
Pull request url: https://github.com/pharo-project/pharo/pull/2066

Issue Url: https://pharo.fogbugz.com/f/cases/22762
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/36/

[Pharo-dev] ‹Programming› 2019 Combined Call for Workshop Submissions

[Fabio Niephaus]

===
‹Programming› 2019 Combined Call for Workshop Submissions
===

To build a community and to foster an environment where participants can
exchange ideas and experiences related to practical software development,
‹Programming› will host a number of workshops, during the days before the
main conference. The workshops will provide a collaborative forum to
exchange recent and/or preliminary results, to conduct intensive
discussions on a particular topic, or to coordinate efforts between
representatives of a technical community. They are intended as a forum for
lively discussion of innovative ideas, recent progress, or practical
experience on programming and applied software development in general for
specific aspects, specific problems, or domain-specific needs. We also
encourage practical, hands-on workshops in which participants actually
experience one or several aspects of practical software development.

The following workshops are co-located with ‹Programming› 2019.


MoreVMs’19: Workshop on Modern Language Runtimes, Ecosystems, and VMs
---
MoreVMs’19 aims to bring together industrial and academic programmers to
discuss the design, implementation, and usage of modern languages and
runtimes. Possible topics include reuse of language runtimes, modular
implementation, language design, and compilation strategies.

Call: https://2019.programming-conference.org/track/MoreVMs-2019
Extended Abstract Deadline: 11 Jan 2019


PX/19 5th Edition of the Programming Experience Workshop
---
The Programming Experience (PX) Workshop is about what happens in that room
when programmers sit down in front of computers and produce code,
especially in an exploratory way. We are interested in this experience of
programming and how to improve and evolve it.

Call: https://2019.programming-conference.org/track/px-2019-papers
Submission Deadline: 27 Jan 2019


VPT 2019: Seventh International Workshop on Program Transformation and
Verification
---
The aim of the workshop is to bring together researchers working in the
fields of Program Verification and Program Transformation. There is a great
potential for beneficial interactions between these two area.  The workshop
will provide a forum where researchers from these fields may interact and
foster new developments. The workshop solicits research, position,
application, and system description papers with a special emphasis on case
studies, demonstrating viability of the interactions between the research
fields of program transformation and program verification in a broad sense.

Call: http://refal.botik.ru/vpt/vpt2019/
Submission Deadline: 8 Jan 2019


LANGETI’19: Languages and Tools for Next Generation Testing
---
The LANGETI workshop invites for submission of research papers and tool
demonstrations developing new languages and tools that explore novel
techniques to test next generation applications. We specially encourage new
ideas on testing and its application domain that will spark discussion
during the workshop.

Call: https://2019.programming-conference.org/track/langeti-2019-papers
Submission Deadline: 11 Jan 2019


PASS’19: Workshop on Programming Across the System Stack (PASS) ’19
---
PASS’19 seeks contributions at the interaction of programming languages and
computer systems, such as programming abstractions for emerging platforms,
runtime performance and energy optimization, software tool support for
systems, systems-level reasoning and verification, language-based security,
and systems programming and debugging.

Call: https://2019.programming-conference.org/home/PASS-2019
Submission Deadline: 15 Jan 2019


ICW 2019: Interconnecting Code Workshop
---
Modern computer systems are often loosely coupled compositions of
heterogeneous components. An important part of modern programming is the
art, science, and engineering of interconnecting disparate code components
to offer larger services in a reliable and scalable manner. The goal of
this workshop is to facilitate an ongoing discussion, and advance the state
of the art of interconnecting code.

Call: https://2019.programming-conference.org/track/icw-2019-papers
Initial Abstract Deadline: 11 Jan 2019


Salon des Refusés 2019
---
Salon des Refusés was an 1863 exhibition of artworks rejected from the
official Paris Salon. We bring the same to programming research, creating a
space for intere

[Pharo-dev] Problem loading a branch of my pharo fork in an image

[Thomas Dupriez]

Hello,

I loaded a branch of my pharo fork in an image using iceberg, but the 
method I was interested in did not change for some reason (my branch's 
latest commit changes this method, but these changes were not visible in 
the image I loaded my branch in).


Does someone has an idea of what could have happened? Did I do something 
wrong?


Here's what I did step-by-step if that helps:

- fresh pharo 7 image
- open iceberg
- repair repository "pharo"
- Clicked "Clone again this repository"
- Chose "Clone remote repository", and put the url of my pharo fork: 
"https://github.com/dupriezt/pharo";

- ok
- wait for loading bar to complete
- pharo repo is marked as "Fetch required. Unknown 67dc1e8"
- repair repository "pharo"
- chose "Discard local changes and checkout an existing branch"
- chose the branch "BreakpointBrowser" from the "origin" remote
- Clicked "checkout" on the checkout preview window
- wait for loading bar to complete
- browse the method WorldState class>>debugOn:
- It is different from the last commit I made to this branch 
(https://github.com/dupriezt/pharo/commit/ead94e32f138eb435a95cd889f77ca39d4c325f4)


Thomas Dupriez

Re: [Pharo-dev] Application entrypoints

[Tim Mackinnon]

Actually - kind of related, how does one know how to reset a framework like 
Seaside, or Zinc etc.

I’ve been thinking about proposing frameworks should have a #reset like pragma 
and then the system menu could find them and show the reset menu for all 
frameworks that provide it. I think applications could do a similar thing - 
have an #applicationStart pragma and then there could be an applications menu 
that listed them all in a convenient menu.

Tim

Sent from my iPhone

> On 13 Dec 2018, at 08:38, nanqueti  wrote:
> 
> 
> we could also use the "script:" annotation, and the system browser
> could show it at the class level (it already shows at the method level)
> 
> nicolas
> 
>> On Thu, 2018-12-13 at 10:40 +0800, Ben Coman wrote:
>> A question was asked on discord... "I know how to start the lights
>> out example, 
>> and feed my objects test data with the testing framework, but how
>> does one start 
>> something like ChineseCheckers? How does one find the entry point? 
>> Is there a convention on naming a starting place?"
>> 
>> I remember having similar thoughts when starting in Pharo.
>> 
>> One convention I have seen is that amongst all the classes presumably
>> prefixed "CC"
>> one class would stand out being named for the application without the
>> prefix. 
>> e.g. class "ChineseCheckers".  That is only a narrow chance for a
>> namespace conflict,
>> the the risk still remains.
>> 
>> I suggested another path would have a package tag "Application" 
>> (i.e. "ChineseCheckers-Application") that contains a single class 
>> which has an #open method on the class-side.
>> The tag "Application" sorts high up on the package-tags and is self-
>> descriptive.
>> But I've not seen that used before, so while I think its a good idea,
>> its not really a convention. 
>> Conventions are only useful if they are broadly understood.
>> 
>> So I'm wondering what other things people do to draw attention to
>> their application entry points.  
>> 
>> cheers -ben
> -- 
> Nicolas Anquetil
> RMod team -- Inria Lille
> 
> 

Re: [Pharo-dev] Problem loading a branch of my pharo fork in an image

[Thomas Dupriez]

I retried what I described below, but this time I cloned my pharo fork 
using the "Clone from github" option instead of the "Clone remote 
repository".


It's better, but not perfect. here are the differences:

- the pharo repo is marked as "Detached working Copy" instead of "Fetch 
required. Unknown 67dc1e8"

- the changes to the WorldState class>>debugOn: were loaded this time
- however, the package I had added to my branch (BreakpointBrowser) was 
not present, and not shown among the packages iceberg showed when 
double-clickig on the pharo repo


Thomas Dupriez

On 13/12/2018 16:18, Thomas Dupriez wrote:

Hello,

I loaded a branch of my pharo fork in an image using iceberg, but the 
method I was interested in did not change for some reason (my branch's 
latest commit changes this method, but these changes were not visible 
in the image I loaded my branch in).


Does someone has an idea of what could have happened? Did I do 
something wrong?


Here's what I did step-by-step if that helps:

- fresh pharo 7 image
- open iceberg
- repair repository "pharo"
- Clicked "Clone again this repository"
- Chose "Clone remote repository", and put the url of my pharo fork: 
"https://github.com/dupriezt/pharo";

- ok
- wait for loading bar to complete
- pharo repo is marked as "Fetch required. Unknown 67dc1e8"
- repair repository "pharo"
- chose "Discard local changes and checkout an existing branch"
- chose the branch "BreakpointBrowser" from the "origin" remote
- Clicked "checkout" on the checkout preview window
- wait for loading bar to complete
- browse the method WorldState class>>debugOn:
- It is different from the last commit I made to this branch 
(https://github.com/dupriezt/pharo/commit/ead94e32f138eb435a95cd889f77ca39d4c325f4)


Thomas Dupriez

Re: [Pharo-dev] Pharo image don't restart

[Trussardi Dario Romano]

Ciao,

> Hi,
> 
> The problem seems to come from: "no room in eden for 
> allocateSmallNewSpaceSlots:format:classIndex:"
> Eden is a part of the heap where new objects are allocated.
> Basically, it appears that Pharo cannot create objects any more.
> You can get information about gc and eden space here: 
> https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
> 
> Could you try to run your image in headless mode to see if it starts?
> ex: 
> 
> I would try to start your image with a bigger size for the eden.
> Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
> parameterAt: 44) * 4.
> but it means you need an image that is started …
> 
> You can also set it as an argument to the VM: --eden [mk]
> 
> You could try with —eden 15207744 for example:
> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
> ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ 
> version\)/Pharo\ 7.0\ -\ 64bit\ \(development\ version\).image 

After copy the pharoLauncher entry with the errorinto 
Pharo7.0-64DTRDevErr entry

i do this:

/opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 
/home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image

the shell report:   

pthread_setschedparam failed: Operation not permitted

*This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat <

Re: [Pharo-dev] Application entrypoints

[Eliot Miranda]

Hi Ben,

On Wed, Dec 12, 2018 at 6:41 PM Ben Coman  wrote:

> A question was asked on discord... "I know how to start the lights out
> example,
> and feed my objects test data with the testing framework, but how does one
> start
> something like ChineseCheckers? How does one find the entry point?
> Is there a convention on naming a starting place?"
>
> I remember having similar thoughts when starting in Pharo.
>
> One convention I have seen is that amongst all the classes presumably
> prefixed "CC"
> one class would stand out being named for the application without the
> prefix.
> e.g. class "ChineseCheckers".  That is only a narrow chance for a
> namespace conflict,
> the the risk still remains.
>
> I suggested another path would have a package tag "Application"
> (i.e. "ChineseCheckers-Application") that contains a single class
> which has an #open method on the class-side.
> The tag "Application" sorts high up on the package-tags and is
> self-descriptive.
> But I've not seen that used before, so while I think its a good idea, its
> not really a convention.
> Conventions are only useful if they are broadly understood.
>
> So I'm wondering what other things people do to draw attention to their
> application entry points.
>

I use a combination of class-side categories (instance creation, examples,
api, etc) and class comments.  e.g. in the class comment
for StackInterpreterSimulator in VMMaker you'll find:

| vm |
vm := StackInterpreterSimulator newWithOptions: #().
vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'.
vm setBreakSelector: #&.
vm openAsMorph; run

But the above is hard to find.  I buy Doru's examples approach.  Usually
interesting objects are used in some kind of context and there may be a
flow that the above illustrates, instantiation => initialization => use.
All this is possible with examples, and examples have a pragma to identify
them to tools.  So I would push the examples direction. I guess the kernel
of this approach is to create a method that creates and uses some object,
and that is labelled with a specific pragma identifying it as an example.
It can then serve as both a test and an example to users.


> cheers -ben
>

_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Pharo image don't restart

[Eliot Miranda]

Hi All,

> On Dec 13, 2018, at 5:40 AM, Christophe Demarey  
> wrote:
> 
> Hi,
> 
> The problem seems to come from: "no room in eden for 
> allocateSmallNewSpaceSlots:format:classIndex:"

Then there should be a crash.dmp file that includes a stack trace.  I’m 
surprised the VM exists by this path; I would expect  the system to retry the 
allocation with an old space allocation that should work.

So, Dario, please keep a copy of your image and changes.  And please email me 
the crash.dmp file.  Create a clean one by deleting it first and then running 
the system until it fails and exits.  Multiple exits append to the crash.dmp 
file so it can end up being quite large.

> Eden is a part of the heap where new objects are allocated.
> Basically, it appears that Pharo cannot create objects any more.
> You can get information about gc and eden space here: 
> https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
> 
> Could you try to run your image in headless mode to see if it starts?
> ex: 
> 
> I would try to start your image with a bigger size for the eden.
> Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
> parameterAt: 44) * 4.
> but it means you need an image that is started …
> 
> You can also set it as an argument to the VM: --eden [mk]
> 
> You could try with —eden 15207744 for example:
> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
> ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ 
> version\)/Pharo\ 7.0\ -\ 64bit\ \(development\ version\).image 
> 
> Regards,
> Christophe
> 
> 
>> Le 13 déc. 2018 à 09:25, Trussardi Dario Romano  
>> a écrit :
>> 
>> Ciao,
>> 
>>  i have a Ubuntu system
>> where i defined a Pharo 7.0 - 64bit image managed with 
>> PharoLauncher.
>> 
>>  I work with it for a month and all work fine.
>> 
>>  Now after a save the image the system begin unstabled.
>> 
>>  When the mouse go on the windows summary bar ( at the bottom of the 
>> Pharo window ) the image go down.
>> 
>>  The first time i can launch the same image from the PharoLauncher,
>> 
>>  but after a new  image  save ( the image go down ) i can't 
>> relaunch the image.
>> 
>>  When i do the launch the pharoLauch shell report:
>> 
>> 
>> 
>>  I have some important work in the image ( and i don't have a backup )
>> 
>>  Some consideration?
>> 
>>  Thanks,
>>  Dario
>> 
> 

Re: [Pharo-dev] [Vm-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

[Nicolas Cellier]

Unfortunately you are right, thru system() call, there's no way to avoid
the window popping up AFAIK.
The library you are using, whatever it is, should invoke lower level API.

The one from Levente (as indicated by Guile) souds OK from a rapid scan of
source code.
https://github.com/astares/Pharo-OS-Windows is not very far either with
some little modifications, and is FFI based.
so it's just a matter of picking code from here and there until libraries
are powerful enough...

IMO, there's no point in maintaining N different libraries, each with own
flaw.
I've always seen such fragmentation as a weakness (IOW it's a failure of
core library to provide standard useful feature).
I can understand that one alternative is FFI based, the other plugin based.
But at the end, each should do the right thing or die.

Le jeu. 13 déc. 2018 à 17:44, Christopher Fuhrman <
christopher.fuhr...@inria.fr> a écrit :

>
> On Wed, 12 Dec 2018 at 11:55, Guillermo Polito 
> wrote:
>
>> Hi all,
>>
>> I think that Christopher and Peter are talking about ProcessWrapper and
>> not OSProcess,
>>
>
> Thanks to all who answered. I'm primarily interested in staying with LibC
> because of its simplicity, robustness and its cross-platform compatibility
> (although I have yet to run some of my code on Linux). From what I
> understand after talking with Esteban, the ffi call to system()
> in msvcrt.dll doesn't have any way to specify the Windows' option for the
> CMD.EXE window, e.g., SW_HIDE.
>
> I have other ideas that maybe a future VM could implementation could
> consider (if that's where the change would need to go), including
> specifying a SETENV variable that is pharo-LibC-specific for turning on/off
> the CMD.exe window.
>
> Christopher
>
>
>> which is fetched from here:
>>
>> http://leves.web.elte.hu/ProcessWrapper/
>>
>> I think this was originally Levente's work?
>> The source code is stored in a zip next to the dll in the same server, no
>> history attached to it.
>>
>> Guille
>>
>> On Wed, Dec 12, 2018 at 12:30 AM Eliot Miranda 
>> wrote:
>>
>>>
>>> Hi Nicolas,
>>>
>>> On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>>

 I've checked: it's a one liner to be changed in
 https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Win32OSProcessPlugin/Win32OSProcessPlugin.c
 near line 826

>>>
>>> So what changes do you want exactly?  I'm happy to do the
>>> Smalltalk/Slang writing (adding the parameter, etc) but I don't know what
>>> result you'd like to see.  Can you post the body of the function as you'd
>>> like to see it or the lines around line 826?
>>>
>>>
 Since this is generated code from VMMaker, the code has to be changed
 in slang.
 IMO, there should be a boolean argument (optional) telling if we want
 to open the console or not.
 IMO false by default would be a good thing, though true for backward
 compatibility is also a possible alternative...

 Le mar. 11 déc. 2018 à 12:56, Nicolas Cellier <
 nicolas.cellier.aka.n...@gmail.com> a écrit :

> It is possible, ask stack overflow
>
> https://stackoverflow.com/questions/4743559/how-to-execute-child-console-programs-without-showing-the-console-window-from-th
>
> https://stackoverflow.com/questions/18841971/hide-console-window-while-running-a-command-through-c?r=SearchResults
>
> I've recently "fixed" my own script in Visualworks so as to use these
> low level API (already procided by VW)
>
>   BOOL CreateProcessW(
> LPCWSTR imageName,
> LPCWSTR commandLine,
> struct SECURITY_ATTRIBUTES *pSecurity,
> struct SECURITY_ATTRIBUTES *tSecurity,
> BOOL inheritHandles,
> DWORD creationFlags,
> LPVOID environment,
> LPWSTR currentDirectoryName,
> struct STARTUPINFO *startupInfo,
> struct PROCESS_INFORMATION *processInfo)
>
> First argument is fullpath to cmd.exe (take it from environment
> variable 'ComSpec')
> Second argument is '/u /c ' ,  'your command here encoded in utf16'
> Security arguments are nil and nil
> inheritHandles is true
> creationFlags is zero
> environment is nil
> currentDirectoryName is nil
>
> startupInfo is more involved: it must be used to pass the pair of
> pipes (handles) for input/output:
> struct STARTUPINFO {
> DWORDcb;
> LPTSTRlpReserved;
> LPTSTRlpDesktop;
> LPTSTRlpTitle;
> DWORDdwX;
> DWORDdwY;
> DWORDdwXSize;
> DWORDdwYSize;
> DWORDdwXCountChars;
> DWORDdwYCountChars;
>>

Re: [Pharo-dev] Pharo image don't restart

[Trussardi Dario Romano]

Ciao,

> Hi All,
> 
> On Dec 13, 2018, at 5:40 AM, Christophe Demarey  
> wrote:
> 
>> Hi,
>> 
>> The problem seems to come from: "no room in eden for 
>> allocateSmallNewSpaceSlots:format:classIndex:"
> 
> Then there should be a crash.dmp file that includes a stack trace.  I’m 
> surprised the VM exists by this path; I would expect  the system to retry the 
> allocation with an old space allocation that should work.
> 
> So, Dario, please keep a copy of your image and changes.  And please email me 
> the crash.dmp file.  Create a clean one by deleting it first and then running 
> the system until it fails and exits.  Multiple exits append to the crash.dmp 
> file so it can end up being quite large.

OK.

From pharoLauncher i launch the corrupt image some time,

the  shell report the issue, but don't create the crash.dmp file.

Thanks,

Dario
> 
>> Eden is a part of the heap where new objects are allocated.
>> Basically, it appears that Pharo cannot create objects any more.
>> You can get information about gc and eden space here: 
>> https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
>> 
>> Could you try to run your image in headless mode to see if it starts?
>> ex: 
>> 
>> I would try to start your image with a bigger size for the eden.
>> Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
>> parameterAt: 44) * 4.
>> but it means you need an image that is started …
>> 
>> You can also set it as an argument to the VM: --eden [mk]
>> 
>> You could try with —eden 15207744 for example:
>> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
>> ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ 
>> version\)/Pharo\ 7.0\ -\ 64bit\ \(development\ version\).image 
>> 
>> Regards,
>> Christophe
>> 
>> 
>>> Le 13 déc. 2018 à 09:25, Trussardi Dario Romano 
>>>  a écrit :
>>> 
>>> Ciao,
>>> 
>>> i have a Ubuntu system
>>>where i defined a Pharo 7.0 - 64bit image managed with 
>>> PharoLauncher.
>>> 
>>> I work with it for a month and all work fine.
>>> 
>>> Now after a save the image the system begin unstabled.
>>> 
>>> When the mouse go on the windows summary bar ( at the bottom of the 
>>> Pharo window ) the image go down.
>>> 
>>> The first time i can launch the same image from the PharoLauncher,
>>> 
>>> but after a new  image  save ( the image go down ) i can't 
>>> relaunch the image.
>>> 
>>> When i do the launch the pharoLauch shell report:
>>> 
>>> 
>>> 
>>> I have some important work in the image ( and i don't have a backup )
>>> 
>>> Some consideration?
>>> 
>>> Thanks,
>>> Dario
>>> 
>> 

Re: [Pharo-dev] Pharo image don't restart

[Christophe Demarey]

> Le 13 déc. 2018 à 17:31, Trussardi Dario Romano  
> a écrit :
> 
> Ciao,
> 
>> Hi,
>> 
>> The problem seems to come from: "no room in eden for 
>> allocateSmallNewSpaceSlots:format:classIndex:"
>> Eden is a part of the heap where new objects are allocated.
>> Basically, it appears that Pharo cannot create objects any more.
>> You can get information about gc and eden space here: 
>> https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
>>  
>> 
>> 
>> Could you try to run your image in headless mode to see if it starts?
>> ex: 
>> 
>> I would try to start your image with a bigger size for the eden.
>> Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
>> parameterAt: 44) * 4.
>> but it means you need an image that is started …
>> 
>> You can also set it as an argument to the VM: --eden [mk]
>> 
>> You could try with —eden 15207744 for example:
>> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
>> ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ 
>> version\)/Pharo\ 7.0\ -\ 64bit\ \(development\ version\).image 
> 
> After copy the pharoLauncher entry with the error  into 
> Pharo7.0-64DTRDevErr entry
> 
> i do this:
> 
> /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 
> /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image
> 
> the shell report: 
> 
> pthread_setschedparam failed: Operation not permitted
> 
> *  This VM uses a separate heartbeat thread to update its internal clock
> and handle events.  For best operation, this thread should run at a
> higher priority, however the VM was unable to change the priority.  The
> effect is that heavily loaded systems may experience some latency
> issues.  If this occurs, please create the appropriate configuration
> file in /etc/security/limits.d/ as shown below:
> 
> cat < *  hardrtprio  2
> *  softrtprio  2
> END
> 
> and report to the pharo mailing list whether this improves behaviour.
> 
> You will need to log out and log back in for the limits to take effect.
> For more information please see
> ...r3732#linux
> Errore di segmentazione (core dump creato)
> 
> Any idea  about it?

So you have a segmentation fault. It means the image tries to access a memory 
address outside the memory range of its process.
using gdb on the core dump could help to have more clues: 
https://www.cprogramming.com/debugging/segfaults.html 

Do you also have a segmentation fault if you run the image without the eden 
parameter?

> The * message required some action ?

this message is just a warning. If you want to avoid it, just execute this as 
root:
> cat < *  hardrtprio  2
> *  softrtprio  2
> END

> P.S. I have to conclude that there is no solution?

For now, it is too early to have a conclusion because we do not know what 
caused the crash.
As Eliot said, it could be useful to get the crash.dmp file and the 
PharoDebug.log file.

Re: [Pharo-dev] Pharo image don't restart

[Trussardi Dario Romano]

Ciao,Le 13 déc. 2018 à 17:31, Trussardi Dario Romano  a écrit :Ciao,Hi,The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:"Eden is a part of the heap where new objects are allocated.Basically, it appears that Pharo cannot create objects any more.You can get information about gc and eden space here:Could you try to run your image in headless mode to see if it starts?ex: I would try to start your image with a bigger size for the eden.Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4.but it means you need an image that is started …You can also set it as an argument to the VM: --eden [mk]You could try with —eden 15207744 for example:~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ version\)/Pharo\ 7.0\ -\ 64bit\ \(development\ version\).image After copy the pharoLauncher entry with the error	 into Pharo7.0-64DTRDevErr entryi do this:/opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.imagethe shell report:	pthread_setschedparam failed: Operation not permitted*	 This VM uses a separate heartbeat thread to update its internal clockand handle events.  For best operation, this thread should run at ahigher priority, however the VM was unable to change the priority.  Theeffect is that heavily loaded systems may experience some latencyissues.  If this occurs, please create the appropriate configurationfile in /etc/security/limits.d/ as shown below:cat <*  hardrtprio  2*  softrtprio  2ENDand report to the pharo mailing list whether this improves behaviour.You will need to log out and log back in for the limits to take effect.For more information please see...r3732#linuxErrore di segmentazione (core dump creato)Any idea  about it?So you have a segmentation fault. It means the image tries to access a memory address outside the memory range of its process.using gdb on the core dump could help to have more clues: https://www.cprogramming.com/debugging/segfaults.html	Tomorrow i investigate about it.Do you also have a segmentation fault if you run the image without the eden parameter?	No without eden parameter the system report the basic errorno room in eden for allocateSmallNewSpaceSlots:format:classIndex:

/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo
Pharo VM version: 5.0-201806281256  Thu Jun 28 13:04:44 UTC 2018 gcc 4.8 
[Production Spur 64-bit VM]
Built from: CoInterpreter VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
Revision: VM: 201806281256 .
Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1
Plugins: 201806281256 ..
Build host: Linux travis-job-46342785-b1c1-4811-8c3c-9b2a88ae7ecc 
4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
plugin path:  [default: 
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/]


C stack backtrace & registers:
*/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x41b165]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo(error+0xf)[0x41c87f]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x432b1c]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x43f52d]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x44838f]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae1]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x459e17]
/home/party/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo[0x45aae6]
/home/party/Pharo/vms/70-x64/li