Re: [Pharo-dev] PharoDays: 14/15 June 2018

[Stephane Ducasse]

Hi guys

We decided that we will not organize PharoDays at Lille this year
because this is too much for us.
We cannot organize ESUG and Pharodays (locally), this is too much
stress and extra work.
Now if someone wants to organize some events we will have all our support.

Personally, I decided that I will not spend energy on it because I
simply cannot anymore.
Pharo is taking too much of my time and energy already. I already do
not read this mailing-list
and I do not go on discord because of full saturation and I will
continue to lower the load.

The stress ratio is going too often over the fun one and this is not good.
Since I have to reconsider what I want to do in the future, this is a
good opportunity to reshuffle
the cards.

Stef

On Fri, Mar 23, 2018 at 1:48 PM, Stephan Eggermont  wrote:
> Stephane Ducasse 
> wrote:
>> Hi All
>>
>> We would like to organise PharoDays the 14 and 15 June. Could you tell us
>> if you see big problems from your side before we announce it.
>
> Works better than 7/8, which I cannot make
>
> Stephan Eggermont
>
>
>

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Stephane Ducasse]

My last email on VM topics...

Hi esteban

Just for the record, our team spent a lot of engineering time and
money on Pharo.
May be I forgot some people. Often we bent research projects to
squeese in Pharo activities.

- Pavel 1 year paid for bootstrap and general improvements
- Denis 2 years paid for TelePharo (for research projects)
- Igor 4 years paid for athens, SDL, VM Build, TxText
- Christophe 5 years bootstrap, ci, infras, plauncher, cargo
- Clement two years as young engineer on compiler/VM
- Clement 6 months on Sista

- Camillo 3 years for his Phd
- Guille 3 years for his Phd
- Pablo 3 years for his Phd
- Mariano 3 years for his Phd
- Clement 3 years for thisPhd

- Guille two years on various improvements
- Me several years
- Marcus several years
- Damien on side project
- Esteban 4 years by Inria

- Nicolas Passerini got paid by the consortium 9 months
- Guillermo paid 6 months for database
- you and mariano got paid for side projects for a couple of months

Right now only Esteban is paid by the consortium because this what the
consortium
can pay!

If I sum up Inria put a lot of money on the table compared to the
users and people
benefitting from Pharo. But this is like that.

So I think that the consortium is a positive thing. Some people may
think the contrary.
Now do not expect miracles. A single guy cannot do much.
Retrospectively I think that
I made a mistake pushing to have tools for git. We should have go the
filetree way
and command line and gain 18 months of work. But I cannot be right all
the time.

Now if all the companies doing Pharo would put money on the table then
we could have
another full time engineer working to improve the situation. I hope
that this will happen.

Then about the VM: a VM is a complex piece of engineering.
And in the open-source community people apparently like to put in addition
not good process and extra constraints (super compatibility, different
dialects), not good communication,
So we end up with a not good situation.

Now I will not read and send any emails about the VM in the future. I
have a set a filter to
automatically trash any emails on the topic. So if you send me an
email and you see now reaction it is normal.
I think that we make no progress and we are even on regression on this part.

We will talk with the consortium members and asked them what is the priority
and if the VM is one of them, then we will have to take real decisions
to make progress.
Now since we cannot form someone on VM core rapidly we will see what are the
options. But to me what is clear is that the situation cannot continue
to be like that.
We cannot not control our process.

Stef


On Sun, Apr 1, 2018 at 6:02 PM, Esteban A. Maringolo
 wrote:
> Stef,
>
> I encourage you to disclose as much details as possible.
>
> For "bystanders" as myself, it is, a Pharo _user_ that always thinks
> of Pharo as the first option but
> doesn't contribute to the core of it,  all this discussions only add
> noise and concerns about the
> stability of the whole Pharo ecosystem.
>
> I've always had  the impression that Pharo is heavily dependent on
> INRIA's/government institutions,
> which in the end depend on political decisions instead of
> "market/profit" objectives.
> With the support of members of the Consortium I thought this had changed, but
> reading your statements it seems it is not enough.
>
> It is known you don't have the best temper, but it is also known you
> strive to get the best for Pharo,
> so if you're also aware of that you can avoid restraining yourself,
> and say what you have
> in mind trying to not make personal accusations.
>
> I'd prefer a brutal and noisy truth instead of false quiet calm.
>
> I hope this helps.
>
> Regards,
>
> Esteban A. Maringolo
>
>
> 2018-04-01 10:16 GMT-03:00 Stephane Ducasse :
>> I will not reply publicly to this email because I think that it will get 
>> worse.
>> So I will not talk publicly about anything related to the Pharo VM in
>> the Pharo mailing-list and any other lists.
>> I will put a filter and trash emails automatically. Like that I will
>> get touched anymore by what I see.
>>
>> You may think that I'm wrong. I'm probably.
>>
>> Now just to make clear: I funded all the PhD of Clement, and all the
>> work of Igor around the VM.
>> And many other engineers and PhD (C. Bruni, Sophie, ...)
>> I'm fighting to make the Pharo consortium working so that we can pay
>> people like Esteban
>> (Esteban is not working in Pharo just because he cannot find a job
>> outside our little community and this
>> is the case for many other people) and other people.
>>
>> Stef
>>
>> On Sun, Apr 1, 2018 at 2:33 PM, Nicolas Cellier
>>  wrote:
>>>
>>>
>>> 2018-04-01 11:36 GMT+02:00 Stephane Ducasse :

 Hi Torsten

 Thanks for this question.

 Ephemerons do not work in Pharo sadly and we know it. We cannot then
 take 

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

[Eliot Miranda]

Hi Alistair,

_,,,^..^,,,_ (phone)

> On Mar 31, 2018, at 1:42 PM, Alistair Grant  wrote:
> 
> Hi Pablo & Eliot,
> 
>> On 31 March 2018 at 20:49, Eliot Miranda  wrote:
>> Hi Pablo,
>> 
>> On Sat, Mar 31, 2018 at 10:19 AM, teso...@gmail.com 
>> wrote:
>>> 
>>> Hi,
>>> I am taking the VM from the latest VM in
>>> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo
>>> scripts, I believe is
>>> http://files.pharo.org/get-files/70/pharo-mac-latest.zip)
>>> The output of version in the VM is:
>>> 
>>> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler:
>>> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM]
>>> 
>>> CoInterpreter VMMaker.oscog-eem.2347 uuid:
>>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>>> 
>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid:
>>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>>> 
>>> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>> Date: Thu Mar 15 20:36:43 2018 +0100 $
>>> 
>>> Plugins: 201803151936
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>> 
>>> 
>>> I don't know if this information helps you to know the specific commit,
>>> but please feel free to tell me how I can get the exact commit from the VM.
>>> Or where to get other VMs to check the error.
>> 
>> 
>> The best one can do is either
>> - running the VM executable from the command line using --version
>> - via the System Reporter
>> 
>> Alas git doesn't help here.  Unlike many other scc systems git doesn't
>> provide a metalanguage to embed the current commit id into source.  The best
>> we have is the time stamp and as we can see the granularity isn't good
>> enough when things are changing quickly.
> 
> git doesn't provide a substitution mechanism like sccs, but the script
> we have that embeds the date can just as easily embed the hash.  In
> .git_filters/RevDateURL.smudge there's a line that retrieves the
> commit date from git:
> 
> $date = `git log --format=%ad -1`;
> 
> to get the (short) hash we can simply add:
> 
> $shorthash = `git log --format=%h -1`;
> 
> The string substitution can then proceed as for the date.
> 
> I think it would be worthwhile having both the date and hash in the
> --version info.
> 
> I'm happy to add this in and update the --version output if there's
> general agreement.

Yes please!!! The conventional alternative is to invoke git log from the 
makefiles and lass in the commit hash as a compiler-line default me.  But this 
is messy and slows down compilation (unless there is a special rule for just 
one file, and that's fragile).  I much prefer having the commit somewhere in 
source.

If you do go ahead with this also consider modifying the makefiles to ensure 
that updateSCCSVersions has been run at least once before the bulk of the build 
is done.

> 
> 
> 
>> As Alistair says, the issue is fixed in the VMMaker.oscog package commit
>> VMMaker.oscog-eem.2359, which is
>> 
>> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
>> Author: Eliot Miranda 
>> Date:   Thu Mar 15 18:09:12 2018 -0700
> 
> 
> Which unfortunately is 1 commit after the version you have.
> 
> There appears to be a separate problem that MacOS VMs aren't being
> uploaded to files.pharo.org, so while running the VM through the Pharo
> automated test suite and bootstrap process is a great idea, right now
> we need to wait for an updated VM for MacOS. :-(.
> 
> 
> Cheers,
> Alistair
> 
> 
> 
>>CogVM source as per VMMaker.oscog-eem.2359
>> 
>>Cogits:
>>Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when
>> improving comoilation breakpoint.  maybeSelectorOfMethod can answer nil so a
>> guard is needed.
>> 
>> I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog
>> commit.  I thought it did.  I'll fix this.
>> 
>>> 
>>> Cheers,
>>> Pablo
>>> 
>>> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant 
>>> wrote:
 
 Hi Pablo,
 
> On 31 March 2018 at 18:36, teso...@gmail.com  wrote:
> Hi Everyone,
>  I have created the PR in Pharo, so the CI runs the bootstrap with the
> latest VM (March 15th).
> Running the process fails during execution of the tests in 32bits OSX.
> It crashes the VM with a segmentation fault.
> I could reproduce the crash, running the tests from the command line,
> and
> also running OCBytecodeGeneratorTest test.
 
 
 There were several VMs built on / around the 15th.  Would you mind
 letting me know the commit hash as Eliot fixed this particular problem
 about then.
 
 I tested 43a2f5c.
 
 Thanks,
 Alistair
 
 
 
> 
> I am attaching the crash.dmp with both executions (from the commandLine
> and
> headful), both are in the same point.
> 
> Cheers,
> Pablo
> 
> On Sat, 

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Esteban A. Maringolo]

Stef,

I encourage you to disclose as much details as possible.

For "bystanders" as myself, it is, a Pharo _user_ that always thinks
of Pharo as the first option but
doesn't contribute to the core of it,  all this discussions only add
noise and concerns about the
stability of the whole Pharo ecosystem.

I've always had  the impression that Pharo is heavily dependent on
INRIA's/government institutions,
which in the end depend on political decisions instead of
"market/profit" objectives.
With the support of members of the Consortium I thought this had changed, but
reading your statements it seems it is not enough.

It is known you don't have the best temper, but it is also known you
strive to get the best for Pharo,
so if you're also aware of that you can avoid restraining yourself,
and say what you have
in mind trying to not make personal accusations.

I'd prefer a brutal and noisy truth instead of false quiet calm.

I hope this helps.

Regards,

Esteban A. Maringolo


2018-04-01 10:16 GMT-03:00 Stephane Ducasse :
> I will not reply publicly to this email because I think that it will get 
> worse.
> So I will not talk publicly about anything related to the Pharo VM in
> the Pharo mailing-list and any other lists.
> I will put a filter and trash emails automatically. Like that I will
> get touched anymore by what I see.
>
> You may think that I'm wrong. I'm probably.
>
> Now just to make clear: I funded all the PhD of Clement, and all the
> work of Igor around the VM.
> And many other engineers and PhD (C. Bruni, Sophie, ...)
> I'm fighting to make the Pharo consortium working so that we can pay
> people like Esteban
> (Esteban is not working in Pharo just because he cannot find a job
> outside our little community and this
> is the case for many other people) and other people.
>
> Stef
>
> On Sun, Apr 1, 2018 at 2:33 PM, Nicolas Cellier
>  wrote:
>>
>>
>> 2018-04-01 11:36 GMT+02:00 Stephane Ducasse :
>>>
>>> Hi Torsten
>>>
>>> Thanks for this question.
>>>
>>> Ephemerons do not work in Pharo sadly and we know it. We cannot then
>>> take advantage of them.
>>> What you see is in fact a degradation of the situation around the VM. :(
>>> We are concerned about this but the path for our future in this domain
>>> is unclear.
>>>
>>
>> Hi Stephane,
>> the future is in your hand.
>> Put milestones on opensmalltalk-vm, open new entries on opensmalltalk-vm
>> issue tracker, put engineering force to solve pharo-specific build failures.
>> In one word, help us to help you.
>>
>> So could you please explain what did you do exactly to help ephemerons being
>> implemented in spur, and what are the forces couter-acting your efforts?
>>
>>
>>>
>>> What is clear is that we will reduce the number of Plugin (as pablo
>>> did for freetype) and use FFI.
>>> But FFI callbacks are not really good. And we need a threaded VM. Now
>>> nothing happens on this front.
>>>
>>
>> Yes, we all want that!
>> It's just that it does not happen by magic nor handwaving.
>>
>>>
>>> Let us face it there is a bad energy around. After years of discussion
>>> our engineers
>>> are still struggling and slowed down because of the dispersion of plugin
>>> code.
>>> In addition, from what I understood there is no development branch :)
>>> amazing is not it in 2020!
>>>
>> How sarcasms are going to  federate and encourage people to make progress?
>> What can you obtain with this sort of sentence but further splitting the
>> community?
>> Is it your goal?
>>
>>>
>>>
>>> On another scale, since 1 year, I was focusing on making that our
>>> institute offers a permanent position to Clement but I failed
>>> because the forces against where too strong (politics) and clement
>>> should reapply next year.
>>> Now to improve his CV, clement is doing a postdoc at VUB and will
>>> start working on Truffle (the VM of Oracle)
>>> and continue to work part time on Sista.
>>> This is not that bad,  like that he will gain experience on other
>>> systems and in the future
>>> we will be in the position to see if there are real alternatives for
>>> us. May be writing a new VM
>>> on top of other existing infrastructure is the way to go. We will see
>>> in the future.
>>>
>>
>> Unfortunately, the rules of French institutions certainly do not help you...
>> Maybe Truffle is a possible future for you, more solid than 100% own fork
>> for sure.
>>
>>
>>> To be fully transparent
>>>
>>> - we will have one phd working on IoT and how to reduce/clean the image
>>> and
>>> VM size and many other points she will probably work on a fork because
>>> I cannot suicide a
>>> student (by asking her to understand the messy plugin architecture)
>>> and she will need some space to experiment.
>>> Now if improvements she will perform take ages to be integrated in the
>>> main VM I will ask
>>> her not to do it and to focus on her future and science.
>>> I imagine that everybody paying attention to people 

[Pharo-dev] Loading code with iceberg

[Javier Pimás]

We are loading some code using Iceberg API in pharo6.1. That works fine,
the problem we have is that when I open Iceberg browser no repo is shown
up. Maybe you can help me find what we are doing wrong. We first update
iceberg, then load our repo, code is below.

Cheers,
Pocho.



Author useAuthor: 'LoadSqueakNOS' during: [
"First update Iceberg"

MetacelloPharoPlatform select.
#(
'BaselineOfTonel'
'BaselineOfLibGit'
'BaselineOfIceberg'
'Iceberg-UI'
'Iceberg-Plugin-GitHub'
'Iceberg-Plugin'
'Iceberg-Metacello-Integration'
'Iceberg-Libgit-Tonel'
'Iceberg-Libgit-Filetree'
'Iceberg-Libgit'
'Iceberg'
'Iceberg-Pharo6'
'LibGit-Core'
'MonticelloTonel-Tests'
'MonticelloTonel-Core'
'MonticelloTonel-FileSystem' )
do: [ :each | (each asPackageIfAbsent: [ nil ]) ifNotNil: #removeFromSystem
].

Metacello new
  baseline: 'Iceberg';
  repository: 'github://pharo-vcs/iceberg:v0.6.8';
  load.
]

"Based on the same file from the pharo-vm project"

myRepository := IceRepositoryCreator new
url: 'g...@github.com:nopsys/CogNOS.git';
subdirectory: 'Image-src';
createRepository.
(myRepository addPackageNamed: 'SqueakNOS') loadLatest.


-- 
Javier Pimás
Ciudad de Buenos Aires

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Stephane Ducasse]

I will not reply publicly to this email because I think that it will get worse.
So I will not talk publicly about anything related to the Pharo VM in
the Pharo mailing-list and any other lists.
I will put a filter and trash emails automatically. Like that I will
get touched anymore by what I see.

You may think that I'm wrong. I'm probably.

Now just to make clear: I funded all the PhD of Clement, and all the
work of Igor around the VM.
And many other engineers and PhD (C. Bruni, Sophie, ...)
I'm fighting to make the Pharo consortium working so that we can pay
people like Esteban
(Esteban is not working in Pharo just because he cannot find a job
outside our little community and this
is the case for many other people) and other people.

Stef

On Sun, Apr 1, 2018 at 2:33 PM, Nicolas Cellier
 wrote:
>
>
> 2018-04-01 11:36 GMT+02:00 Stephane Ducasse :
>>
>> Hi Torsten
>>
>> Thanks for this question.
>>
>> Ephemerons do not work in Pharo sadly and we know it. We cannot then
>> take advantage of them.
>> What you see is in fact a degradation of the situation around the VM. :(
>> We are concerned about this but the path for our future in this domain
>> is unclear.
>>
>
> Hi Stephane,
> the future is in your hand.
> Put milestones on opensmalltalk-vm, open new entries on opensmalltalk-vm
> issue tracker, put engineering force to solve pharo-specific build failures.
> In one word, help us to help you.
>
> So could you please explain what did you do exactly to help ephemerons being
> implemented in spur, and what are the forces couter-acting your efforts?
>
>
>>
>> What is clear is that we will reduce the number of Plugin (as pablo
>> did for freetype) and use FFI.
>> But FFI callbacks are not really good. And we need a threaded VM. Now
>> nothing happens on this front.
>>
>
> Yes, we all want that!
> It's just that it does not happen by magic nor handwaving.
>
>>
>> Let us face it there is a bad energy around. After years of discussion
>> our engineers
>> are still struggling and slowed down because of the dispersion of plugin
>> code.
>> In addition, from what I understood there is no development branch :)
>> amazing is not it in 2020!
>>
> How sarcasms are going to  federate and encourage people to make progress?
> What can you obtain with this sort of sentence but further splitting the
> community?
> Is it your goal?
>
>>
>>
>> On another scale, since 1 year, I was focusing on making that our
>> institute offers a permanent position to Clement but I failed
>> because the forces against where too strong (politics) and clement
>> should reapply next year.
>> Now to improve his CV, clement is doing a postdoc at VUB and will
>> start working on Truffle (the VM of Oracle)
>> and continue to work part time on Sista.
>> This is not that bad,  like that he will gain experience on other
>> systems and in the future
>> we will be in the position to see if there are real alternatives for
>> us. May be writing a new VM
>> on top of other existing infrastructure is the way to go. We will see
>> in the future.
>>
>
> Unfortunately, the rules of French institutions certainly do not help you...
> Maybe Truffle is a possible future for you, more solid than 100% own fork
> for sure.
>
>
>> To be fully transparent
>>
>> - we will have one phd working on IoT and how to reduce/clean the image
>> and
>> VM size and many other points she will probably work on a fork because
>> I cannot suicide a
>> student (by asking her to understand the messy plugin architecture)
>> and she will need some space to experiment.
>> Now if improvements she will perform take ages to be integrated in the
>> main VM I will ask
>> her not to do it and to focus on her future and science.
>> I imagine that everybody paying attention to people can understand this.
>>
>>
>
> Good to know that you are paying attention to people, I had the impression
> that this was not allways the case.
> I'm willing to help Pharo, I've helped producing Pharo brand 64 bits windows
> VM more than one year ago.
> I'm struggling to make the community beneficial to all, but I don't feel
> like I get a lot of support and wonder if I'm not completely mistaken when I
> see all the efforts deployed to tear it apart...
>
>
>>
>> Stef
>>
>> On Tue, Nov 7, 2017 at 9:00 PM, Torsten Bergmann  wrote:
>> > Hi,
>> >
>> > by accident I stumbled upon the following code in
>> > AnnouncementSubscription:
>> >
>> >  makeWeak
>> >action isBlock ifTrue: [ self error: 'Not currently available due to
>> > missing ephemerons support'].
>> >...
>> >
>> > My understanding is that we have Ephemeron support in Pharo now working.
>> > Right?
>> >
>> > Anyone with more insights who knows how to fix/complete this? Should we
>> > at least open an issue?
>> >
>> > Thx
>> > T.
>> >
>> >
>>
>

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Nicolas Cellier]

2018-04-01 11:36 GMT+02:00 Stephane Ducasse :

> Hi Torsten
>
> Thanks for this question.
>
> Ephemerons do not work in Pharo sadly and we know it. We cannot then
> take advantage of them.
> What you see is in fact a degradation of the situation around the VM. :(
> We are concerned about this but the path for our future in this domain
> is unclear.
>
>
Hi Stephane,
the future is in your hand.
Put milestones on opensmalltalk-vm, open new entries on opensmalltalk-vm
issue tracker, put engineering force to solve pharo-specific build failures.
In one word, help us to help you.

So could you please explain what did you do exactly to help ephemerons
being implemented in spur, and what are the forces couter-acting your
efforts?



> What is clear is that we will reduce the number of Plugin (as pablo
> did for freetype) and use FFI.
> But FFI callbacks are not really good. And we need a threaded VM. Now
> nothing happens on this front.
>
>
Yes, we all want that!
It's just that it does not happen by magic nor handwaving.


> Let us face it there is a bad energy around. After years of discussion
> our engineers
> are still struggling and slowed down because of the dispersion of plugin
> code.
> In addition, from what I understood there is no development branch :)
> amazing is not it in 2020!
>
> How sarcasms are going to  federate and encourage people to make progress?
What can you obtain with this sort of sentence but further splitting the
community?
Is it your goal?


>
> On another scale, since 1 year, I was focusing on making that our
> institute offers a permanent position to Clement but I failed
> because the forces against where too strong (politics) and clement
> should reapply next year.
> Now to improve his CV, clement is doing a postdoc at VUB and will
> start working on Truffle (the VM of Oracle)
> and continue to work part time on Sista.
> This is not that bad,  like that he will gain experience on other
> systems and in the future
> we will be in the position to see if there are real alternatives for
> us. May be writing a new VM
> on top of other existing infrastructure is the way to go. We will see
> in the future.
>
>
Unfortunately, the rules of French institutions certainly do not help you...
Maybe Truffle is a possible future for you, more solid than 100% own fork
for sure.


To be fully transparent
>
> - we will have one phd working on IoT and how to reduce/clean the image and
> VM size and many other points she will probably work on a fork because
> I cannot suicide a
> student (by asking her to understand the messy plugin architecture)
> and she will need some space to experiment.
> Now if improvements she will perform take ages to be integrated in the
> main VM I will ask
> her not to do it and to focus on her future and science.
> I imagine that everybody paying attention to people can understand this.
>
>
>
Good to know that you are paying attention to people, I had the impression
that this was not allways the case.
I'm willing to help Pharo, I've helped producing Pharo brand 64 bits
windows VM more than one year ago.
I'm struggling to make the community beneficial to all, but I don't feel
like I get a lot of support and wonder if I'm not completely mistaken when
I see all the efforts deployed to tear it apart...



> Stef
>
> On Tue, Nov 7, 2017 at 9:00 PM, Torsten Bergmann  wrote:
> > Hi,
> >
> > by accident I stumbled upon the following code in
> AnnouncementSubscription:
> >
> >  makeWeak
> >action isBlock ifTrue: [ self error: 'Not currently available due to
> missing ephemerons support'].
> >...
> >
> > My understanding is that we have Ephemeron support in Pharo now working.
> Right?
> >
> > Anyone with more insights who knows how to fix/complete this? Should we
> at least open an issue?
> >
> > Thx
> > T.
> >
> >
>
>

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

[Stephane Ducasse]

Good to know.

On Sun, Apr 1, 2018 at 12:52 PM, Aliaksei Syrel  wrote:
> Hi,
>
> Bintray has 6 months upload limit for the same release. Uploading of a new
> binary to #development release becomes impossible after 6 month since
> creation of that release.
> I have to delete and re-create releases once in a while...
>
> Cheers,
> Alex
>
> On 1 April 2018 at 12:49, Esteban Lorenzano  wrote:
>>
>> hi,
>>
>> On 31 Mar 2018, at 22:42, Alistair Grant  wrote:
>>
>> Hi Pablo & Eliot,
>>
>> On 31 March 2018 at 20:49, Eliot Miranda  wrote:
>>
>> Hi Pablo,
>>
>> On Sat, Mar 31, 2018 at 10:19 AM, teso...@gmail.com 
>> wrote:
>>
>>
>> Hi,
>> I am taking the VM from the latest VM in
>> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo
>> scripts, I believe is
>> http://files.pharo.org/get-files/70/pharo-mac-latest.zip)
>> The output of version in the VM is:
>>
>> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler:
>> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM]
>>
>> CoInterpreter VMMaker.oscog-eem.2347 uuid:
>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>>
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid:
>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>>
>> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>> Date: Thu Mar 15 20:36:43 2018 +0100 $
>>
>> Plugins: 201803151936
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>
>>
>> I don't know if this information helps you to know the specific commit,
>> but please feel free to tell me how I can get the exact commit from the
>> VM.
>> Or where to get other VMs to check the error.
>>
>>
>>
>> The best one can do is either
>> - running the VM executable from the command line using --version
>> - via the System Reporter
>>
>> Alas git doesn't help here.  Unlike many other scc systems git doesn't
>> provide a metalanguage to embed the current commit id into source.  The
>> best
>> we have is the time stamp and as we can see the granularity isn't good
>> enough when things are changing quickly.
>>
>>
>> git doesn't provide a substitution mechanism like sccs, but the script
>> we have that embeds the date can just as easily embed the hash.  In
>> .git_filters/RevDateURL.smudge there's a line that retrieves the
>> commit date from git:
>>
>> $date = `git log --format=%ad -1`;
>>
>> to get the (short) hash we can simply add:
>>
>> $shorthash = `git log --format=%h -1`;
>>
>> The string substitution can then proceed as for the date.
>>
>> I think it would be worthwhile having both the date and hash in the
>> --version info.
>>
>> I'm happy to add this in and update the --version output if there's
>> general agreement.
>>
>>
>>
>> As Alistair says, the issue is fixed in the VMMaker.oscog package commit
>> VMMaker.oscog-eem.2359, which is
>>
>> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
>> Author: Eliot Miranda 
>> Date:   Thu Mar 15 18:09:12 2018 -0700
>>
>>
>>
>> Which unfortunately is 1 commit after the version you have.
>>
>> There appears to be a separate problem that MacOS VMs aren't being
>> uploaded to files.pharo.org, so while running the VM through the Pharo
>> automated test suite and bootstrap process is a great idea, right now
>> we need to wait for an updated VM for MacOS. :-(.
>>
>>
>> I just figured out last green build of Cog was 16 days ago so is correct
>> (and not an error) that no mac build is being copied: there is no build
>> since linux build failed and then no mac build was ran.
>> Is not a problem about mac files copied to pharo file server but a general
>> one (but that does not explains the bintray problem, since last upload there
>> is from 8/03 and there was at least one successful build after)
>>
>> cheers,
>> Esteban
>>
>>
>>
>> Cheers,
>> Alistair
>>
>>
>>
>>CogVM source as per VMMaker.oscog-eem.2359
>>
>>Cogits:
>>Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when
>> improving comoilation breakpoint.  maybeSelectorOfMethod can answer nil so
>> a
>> guard is needed.
>>
>> I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog
>> commit.  I thought it did.  I'll fix this.
>>
>>
>> Cheers,
>> Pablo
>>
>> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant 
>> wrote:
>>
>>
>> Hi Pablo,
>>
>> On 31 March 2018 at 18:36, teso...@gmail.com  wrote:
>>
>> Hi Everyone,
>>  I have created the PR in Pharo, so the CI runs the bootstrap with the
>> latest VM (March 15th).
>> Running the process fails during execution of the tests in 32bits OSX.
>> It crashes the VM with a segmentation fault.
>> I could reproduce the crash, running the tests from the command line,
>> and
>> also running OCBytecodeGeneratorTest test.
>>
>>
>>
>> There were several VMs built on / around the 15th.  Would you mind
>> letting me know 

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

[Stephane Ducasse]

Thanks Pablo for your time and willingness to help.

On Sat, Mar 31, 2018 at 6:36 PM, teso...@gmail.com  wrote:
> Hi Everyone,
>   I have created the PR in Pharo, so the CI runs the bootstrap with the
> latest VM (March 15th).
> Running the process fails during execution of the tests in 32bits OSX.
> It crashes the VM with a segmentation fault.
> I could reproduce the crash, running the tests from the command line, and
> also running OCBytecodeGeneratorTest test.
>
> I am attaching the crash.dmp with both executions (from the commandLine and
> headful), both are in the same point.
>
> Cheers,
> Pablo
>
> On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse 
> wrote:
>>
>> > I will try to promote then the one of 15 march. We’ll see next week.
>> > but then, this is part of my observation: We cannot know which VMs are
>> > stable, and that’s because the *process* to make them stable is very
>> > “human
>> > dependent”: We consider a version stable when it builds on CI and Eliot
>> > says
>> > is stable. But since Eliot does not use Pharo (not a critic, a reality),
>> > that may be not true for Pharo. And that’s actually what happens, Pharo
>> > crashes.
>>
>> Hi esteban
>>
>> What would be a way to fix the process and make your work easier?
>>
>> If you do not know what can be a release candidate then who can?
>> We should really improve this situation.
>>
>> Stef
>>
>>
>> > I tried to avoid a bit this problem with our fork and nightly builds
>> > that
>> > runs the pharo tests (to knew about problems as early as possible). But
>> > to
>> > be honest I didn’t have the time (and the will) to work on it recently,
>> > then
>> > pharo fork is in practice stalled. I will revive that eventually… but
>> > just
>> > when I find the time and the spirit to do it.
>> >
>> >
>> > to one more up to date than 2017 08 27 (in fact more up-to-date than
>> > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri
>> > Jan 19
>> > 13:17:57 2018 -0800).  The bug that VMMaker.oscog-eem.2320 fixes can
>> > result
>> > in image corruption in large images, and can occur (as it has here) at
>> > start-up, causing one's work to be irretrievably lost.
>> >
>> >
>> > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are
>> > triggered either by the automated test suite or the bootstrap process.
>> >
>> >
>> > The blocks I can see at the moment are:
>> >
>> > - Multiple builds have failed with an internal compiler error on the
>> > sista builds.
>> > -- The earliest occurrence I could find was commit 1f0a7da, but it may
>> > have been earlier.
>> > - Even if the Mac builds show success in travis, they aren't making it
>> > on to files.pharo.org.
>> >
>> >
>> > latest VM copied into files.pharo.org is 16/03.
>> > we need to see what’s happening there.
>> >
>> > -- I haven't ever worked with this code.
>> >
>> > Not directly related, but:
>> > - Bintray hasn't been updated since 8 March 2018.
>> >
>> >
>> > I think it could also be useful for files.pharo.org to have release
>> > candidate links available, which would help people to focus testing on
>> > a particular VM.  They would need to be manually maintained, but I
>> > think the benefits would be worthwhile.
>> >
>> >
>> > all VMs are available to test.
>> > just… not available *directly* to general users.
>> > now… I could have a 70rc link in vm subdir. But since I cannot know
>> > which VM
>> > is RC I find it pointless at this moment.
>> >
>> > cheers,
>> > Esteban
>> >
>> >
>> >
>> > Cheers,
>> > Alistair
>> >
>> >
>>
>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

[Stephane Ducasse]

>
> I didn't mean that we would always be looking to release a new version,
> but there have been multiple occassions in the past when you've asked
> people to try a particular VM to see if it solves a problem.  In those
> instances, marking it as RC would make it simpler for others to
> contribute to the testing and give you more confidence to promote it to
> stable.
>
> Actually, if the link existed all the time, but most of the time it was
> the same as the stable version, I'd probably just use it as my download
> link, which would mean that I'm testing the RC whenever it comes out,
> and stay with it while it is stable and there isn't a new RC.

Yes this would be a good idea.

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

[Aliaksei Syrel]

Hi,

Bintray has 6 months upload limit for the same release. Uploading of a new
binary to #development release becomes impossible after 6 month since
creation of that release.
I have to delete and re-create releases once in a while...

Cheers,
Alex

On 1 April 2018 at 12:49, Esteban Lorenzano  wrote:

> hi,
>
> On 31 Mar 2018, at 22:42, Alistair Grant  wrote:
>
> Hi Pablo & Eliot,
>
> On 31 March 2018 at 20:49, Eliot Miranda  wrote:
>
> Hi Pablo,
>
> On Sat, Mar 31, 2018 at 10:19 AM, teso...@gmail.com 
> wrote:
>
>
> Hi,
> I am taking the VM from the latest VM in
> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo
> scripts, I believe is
> http://files.pharo.org/get-files/70/pharo-mac-latest.zip)
> The output of version in the VM is:
>
> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler:
> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM]
>
> CoInterpreter VMMaker.oscog-eem.2347 uuid:
> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>
> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid:
> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>
> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> Date: Thu Mar 15 20:36:43 2018 +0100 $
>
> Plugins: 201803151936
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>
>
> I don't know if this information helps you to know the specific commit,
> but please feel free to tell me how I can get the exact commit from the VM.
> Or where to get other VMs to check the error.
>
>
>
> The best one can do is either
> - running the VM executable from the command line using --version
> - via the System Reporter
>
> Alas git doesn't help here.  Unlike many other scc systems git doesn't
> provide a metalanguage to embed the current commit id into source.  The
> best
> we have is the time stamp and as we can see the granularity isn't good
> enough when things are changing quickly.
>
>
> git doesn't provide a substitution mechanism like sccs, but the script
> we have that embeds the date can just as easily embed the hash.  In
> .git_filters/RevDateURL.smudge there's a line that retrieves the
> commit date from git:
>
> $date = `git log --format=%ad -1`;
>
> to get the (short) hash we can simply add:
>
> $shorthash = `git log --format=%h -1`;
>
> The string substitution can then proceed as for the date.
>
> I think it would be worthwhile having both the date and hash in the
> --version info.
>
> I'm happy to add this in and update the --version output if there's
> general agreement.
>
>
>
> As Alistair says, the issue is fixed in the VMMaker.oscog package commit
> VMMaker.oscog-eem.2359, which is
>
> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
> Author: Eliot Miranda 
> Date:   Thu Mar 15 18:09:12 2018 -0700
>
>
>
> Which unfortunately is 1 commit after the version you have.
>
> There appears to be a separate problem that MacOS VMs aren't being
> uploaded to files.pharo.org, so while running the VM through the Pharo
> automated test suite and bootstrap process is a great idea, right now
> we need to wait for an updated VM for MacOS. :-(.
>
>
> I just figured out last green build of Cog was 16 days ago so is correct
> (and not an error) that no mac build is being copied: there is no build
> since linux build failed and then no mac build was ran.
> Is not a problem about mac files copied to pharo file server but a general
> one (but that does not explains the bintray problem, since last upload
> there is from 8/03 and there was at least one successful build after)
>
> cheers,
> Esteban
>
>
>
> Cheers,
> Alistair
>
>
>
>CogVM source as per VMMaker.oscog-eem.2359
>
>Cogits:
>Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when
> improving comoilation breakpoint.  maybeSelectorOfMethod can answer nil so
> a
> guard is needed.
>
> I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog
> commit.  I thought it did.  I'll fix this.
>
>
> Cheers,
> Pablo
>
> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant 
> wrote:
>
>
> Hi Pablo,
>
> On 31 March 2018 at 18:36, teso...@gmail.com  wrote:
>
> Hi Everyone,
>  I have created the PR in Pharo, so the CI runs the bootstrap with the
> latest VM (March 15th).
> Running the process fails during execution of the tests in 32bits OSX.
> It crashes the VM with a segmentation fault.
> I could reproduce the crash, running the tests from the command line,
> and
> also running OCBytecodeGeneratorTest test.
>
>
>
> There were several VMs built on / around the 15th.  Would you mind
> letting me know the commit hash as Eliot fixed this particular problem
> about then.
>
> I tested 43a2f5c.
>
> Thanks,
> Alistair
>
>
>
>
> I am attaching the crash.dmp with both executions (from the commandLine
> and
> headful), both are in the same point.
>
> Cheers,
> Pablo

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

[Esteban Lorenzano]

hi,

> On 31 Mar 2018, at 22:42, Alistair Grant  wrote:
> 
> Hi Pablo & Eliot,
> 
> On 31 March 2018 at 20:49, Eliot Miranda  > wrote:
>> Hi Pablo,
>> 
>> On Sat, Mar 31, 2018 at 10:19 AM, teso...@gmail.com 
>> wrote:
>>> 
>>> Hi,
>>> I am taking the VM from the latest VM in
>>> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo
>>> scripts, I believe is
>>> http://files.pharo.org/get-files/70/pharo-mac-latest.zip)
>>> The output of version in the VM is:
>>> 
>>> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler:
>>> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM]
>>> 
>>> CoInterpreter VMMaker.oscog-eem.2347 uuid:
>>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>>> 
>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid:
>>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>>> 
>>> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>> Date: Thu Mar 15 20:36:43 2018 +0100 $
>>> 
>>> Plugins: 201803151936
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>>> 
>>> 
>>> I don't know if this information helps you to know the specific commit,
>>> but please feel free to tell me how I can get the exact commit from the VM.
>>> Or where to get other VMs to check the error.
>> 
>> 
>> The best one can do is either
>> - running the VM executable from the command line using --version
>> - via the System Reporter
>> 
>> Alas git doesn't help here.  Unlike many other scc systems git doesn't
>> provide a metalanguage to embed the current commit id into source.  The best
>> we have is the time stamp and as we can see the granularity isn't good
>> enough when things are changing quickly.
> 
> git doesn't provide a substitution mechanism like sccs, but the script
> we have that embeds the date can just as easily embed the hash.  In
> .git_filters/RevDateURL.smudge there's a line that retrieves the
> commit date from git:
> 
> $date = `git log --format=%ad -1`;
> 
> to get the (short) hash we can simply add:
> 
> $shorthash = `git log --format=%h -1`;
> 
> The string substitution can then proceed as for the date.
> 
> I think it would be worthwhile having both the date and hash in the
> --version info.
> 
> I'm happy to add this in and update the --version output if there's
> general agreement.
> 
> 
> 
>> As Alistair says, the issue is fixed in the VMMaker.oscog package commit
>> VMMaker.oscog-eem.2359, which is
>> 
>> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
>> Author: Eliot Miranda > >
>> Date:   Thu Mar 15 18:09:12 2018 -0700
> 
> 
> Which unfortunately is 1 commit after the version you have.
> 
> There appears to be a separate problem that MacOS VMs aren't being
> uploaded to files.pharo.org , so while running the 
> VM through the Pharo
> automated test suite and bootstrap process is a great idea, right now
> we need to wait for an updated VM for MacOS. :-(.

I just figured out last green build of Cog was 16 days ago so is correct (and 
not an error) that no mac build is being copied: there is no build since linux 
build failed and then no mac build was ran.
Is not a problem about mac files copied to pharo file server but a general one 
(but that does not explains the bintray problem, since last upload there is 
from 8/03 and there was at least one successful build after)

cheers,
Esteban

> 
> 
> Cheers,
> Alistair
> 
> 
> 
>>CogVM source as per VMMaker.oscog-eem.2359
>> 
>>Cogits:
>>Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when
>> improving comoilation breakpoint.  maybeSelectorOfMethod can answer nil so a
>> guard is needed.
>> 
>> I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog
>> commit.  I thought it did.  I'll fix this.
>> 
>>> 
>>> Cheers,
>>> Pablo
>>> 
>>> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant 
>>> wrote:
 
 Hi Pablo,
 
 On 31 March 2018 at 18:36, teso...@gmail.com  wrote:
> Hi Everyone,
>  I have created the PR in Pharo, so the CI runs the bootstrap with the
> latest VM (March 15th).
> Running the process fails during execution of the tests in 32bits OSX.
> It crashes the VM with a segmentation fault.
> I could reproduce the crash, running the tests from the command line,
> and
> also running OCBytecodeGeneratorTest test.
 
 
 There were several VMs built on / around the 15th.  Would you mind
 letting me know the commit hash as Eliot fixed this particular problem
 about then.
 
 I tested 43a2f5c.
 
 Thanks,
 Alistair
 
 
 
> 
> I am attaching the crash.dmp with both executions (from the commandLine
> and
> headful), both are in the same point.
> 
> Cheers,
> Pablo
> 

Re: [Pharo-dev] Roadmap to Pharo 7 Release

[Stephane Ducasse]

Hi Peter

Now we do not want to rely on Glamour. You should pay attention since
it is not maintained and producing memory leaks
and we would like to avoid to have to fight to find them.
I do not know what are the plans of feenk at this level.
This is why we started to redesign Spec.

Stef

On Sat, Mar 31, 2018 at 8:58 PM, Peter Uhnák  wrote:
>
>
> On Sat, Mar 31, 2018 at 7:52 PM, Esteban Lorenzano 
> wrote:
>>
>>
>>
>> On 31 Mar 2018, at 17:17, Peter Uhnák  wrote:
>>
>> What does this means for end users?
>>
>>
>> nothing.
>> we are removing some *users* of glamour.
>> Not glamour itself and certainly not the gttools that use glamour
>> intensively (and they allow easy extension).
>
>
> Aaah. My heart skipped originally, now I am at peace. :)
>
>> ps: but there are leaks around we would like to discover how and when they
>> happen (because they are not so many and not evident). Any help there is
>> welcome :)
>
>
> I'll keep that in mind, although I don't usually check whether there are any
> pointers dangling.
>
> Thanks!
> Peter

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Stephane Ducasse]

Hi Torsten

Thanks for this question.

Ephemerons do not work in Pharo sadly and we know it. We cannot then
take advantage of them.
What you see is in fact a degradation of the situation around the VM. :(
We are concerned about this but the path for our future in this domain
is unclear.

What is clear is that we will reduce the number of Plugin (as pablo
did for freetype) and use FFI.
But FFI callbacks are not really good. And we need a threaded VM. Now
nothing happens on this front.

Let us face it there is a bad energy around. After years of discussion
our engineers
are still struggling and slowed down because of the dispersion of plugin code.
In addition, from what I understood there is no development branch :)
amazing is not it in 2020!


On another scale, since 1 year, I was focusing on making that our
institute offers a permanent position to Clement but I failed
because the forces against where too strong (politics) and clement
should reapply next year.
Now to improve his CV, clement is doing a postdoc at VUB and will
start working on Truffle (the VM of Oracle)
and continue to work part time on Sista.
This is not that bad,  like that he will gain experience on other
systems and in the future
we will be in the position to see if there are real alternatives for
us. May be writing a new VM
on top of other existing infrastructure is the way to go. We will see
in the future.

To be fully transparent

- we will have one phd working on IoT and how to reduce/clean the image and
VM size and many other points she will probably work on a fork because
I cannot suicide a
student (by asking her to understand the messy plugin architecture)
and she will need some space to experiment.
Now if improvements she will perform take ages to be integrated in the
main VM I will ask
her not to do it and to focus on her future and science.
I imagine that everybody paying attention to people can understand this.



Stef

On Tue, Nov 7, 2017 at 9:00 PM, Torsten Bergmann  wrote:
> Hi,
>
> by accident I stumbled upon the following code in AnnouncementSubscription:
>
>  makeWeak
>action isBlock ifTrue: [ self error: 'Not currently available due to 
> missing ephemerons support'].
>...
>
> My understanding is that we have Ephemeron support in Pharo now working. 
> Right?
>
> Anyone with more insights who knows how to fix/complete this? Should we at 
> least open an issue?
>
> Thx
> T.
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #748: SUCCESS

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #748 was: SUCCESS.

Could not extract further issue information from commit message: 
https://github.com/pharo-project/pharo/pull/1175

https://pharo.manuscript.com/f/cases/10181
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/748/