Roassal tests make moose6.1 build crashing
by Blondeau Vincent
Hi,
The last changes on Roassal2 seems to make the actual job stopping in the middle of the tests: https://ci.inria.fr/moose/job/roassal2/.
And make the moose6.1 failing too...
Can someone fix this problem?
Else, I'll skip the Roassal tests to make the job green again (and integrate the latest changes).
Thanks in advance !
Cheers,
Vincent
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
6 years, 6 months
Remote publish (but to a hard drive)?
by Cris Fuhrman
Hello all,
I recently discovered Remote Publish for Playgrounds in Pharo. I'm
wondering if there's a way to do the same thing, but to a specified file on
my hard drive?
As it stands, much of my Roassal experiments are in the Playground and I
have been saving images (!) since I could not find a "Save as..." for the
text file in the Playground.
With big Moose models, saving images is overkill. The (non-lazy)
alternative is to select all text in the Playground and copy/paste it into
a Notepad++ file.
Cheers,
C. Fuhrman
6 years, 6 months
Improved Grapher way of stacking data
by Alexandre Bergel
Hi!
Just to share an improvement of Grapher, which is part of Roassal.
The code:
| b d classes |
classes := (Collection withAllSubclasses reverseSortedAs: #numberOfMethods) first: 10.
b := RTGrapher new.
d := RTVerticalMultipleData new.
d points: classes.
d addMetric: #numberOfLinesOfCode.
d addMetric: #numberOfMethods.
d barChartWithBarTitle: #name rotation: -30.
b add: d.
b
Produces:
And this code:
| b d classes |
classes := (Collection withAllSubclasses reverseSortedAs: #numberOfMethods) first: 10.
b := RTGrapher new.
d := RTHorizontalMultipleData new.
d points: classes.
d addMetric: #numberOfLinesOfCode.
d addMetric: #numberOfMethods.
d barChartWithBarTitle: #name rotation: -30.
b add: d.
b
Produces:
Naturally, you can add several metrics:
Consider:
| b d classes |
b := RTGrapher new.
d := RTHorizontalMultipleData new.
d points: #( #('hello' 1 2 1) #('world' 2 4 2) #('bonjour' 3 5 4) #('Gutten Morgen' -1 4 -5)).
d addMetric: #second.
d addMetric: #third.
d addMetric: #fourth.
d barChartWithBarTitle: #first rotation: -30.
b add: d.
b
And:
| b d classes |
b := RTGrapher new.
d := RTVerticalMultipleData new.
d points: #( #('hello' 1 2 1) #('world' 2 4 2) #('bonjour' 3 5 4) ).
d addMetric: #second.
d addMetric: #third.
d addMetric: #fourth.
d barChartWithBarTitle: #first rotation: -30.
b add: d.
b
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
6 years, 6 months
A quick analyzis of the usage of instance variables in Moose
by Guillaume Larcheveque
Hi Moose users,
as you may know, at Synectique we experiment lots of issues about memory
usage.
That's why i had a look at the number of unused instance variables in one
of our system loaded with a big model from one of our main customer.
Total instance variables: 26.852.653
Used instance variables: 17.393.938
Empty collections: 5.023.508
Recoverable instance variables: 14.482.223
The recoverable instance variables are those with nil or an empty
collection (or MultiValueLink)
As you can see, we can save a lot of memory :-)
Here is my (dirty) code to get that:
countUsedInstanceVariableInForSubInstances: aClass
| usedInstNbr instNbr emptyCollNbr |
usedInstNbr := 0.
instNbr := 0.
emptyCollNbr := 0.
aClass
allSubInstancesDo: [ :anEntity |
instNbr := instNbr + anEntity class allInstVarNames size.
anEntity class allInstVarNames
doWithIndex: [ :e :i |
(anEntity instVarAt: i)
ifNotNil: [ :content |
([
content isEmpty.
emptyCollNbr := emptyCollNbr + 1.
false ]
on: MessageNotUnderstood
do: [ false ])
ifFalse: [ usedInstNbr := usedInstNbr + 1 ] ] ] ].
^ {('Used instance variables' -> usedInstNbr).
('empty collections' -> emptyCollNbr).
('Recoverable instance variables' -> (instNbr - (usedInstNbr -
emptyCollNbr))).
('Total instance variables' -> instNbr)}
--
*Guillaume Larcheveque*
6 years, 6 months
Re: [Pharo-dev] Re: Segmentation fault on Moose 6.1 Build
by Tudor Girba
Thanks.
I have switched the Moose job back to using the latest image. Let’s see how it works.
Cheers,
Doru
> On Mar 3, 2017, at 9:19 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote:
>
> Esteban created a working fix for this issue.
>
> Cheers,
> -- Pavel
>
> 2017-03-03 3:16 GMT+01:00 Ben Coman <btc(a)openinworld.com>:
> To confirm specific reproducibility, using...
> http://files.pharo.org/image/60/60421.zip
>
> I did...
> $ cd opensmalltalk-vm
> $ git checkout d54edc56
> $ git log
> commit d54edc5638c9f90c80f214e59e19240f8ead87f8
> Author: Eliot Miranda <eliot.miranda(a)gmail.com>
> Date: Thu Mar 2 09:53:05 2017 -0800
> CogVM source as per VMMaker.oscog-eem.2143
> Fix regression in Sista sources due to receiverTags work.
>
> $ cd build.linux32x86/pharo.cog.spur/build.debug
> $ cd products/debug/phcogspurlinuxht
> $ pharo ~/temp/Case19785/Pharo-60421.image
>
> World > Playground, evaluate...
> surf := AthensCairoSurface extent: Display extent.
> Display getCanvas drawImage: surf asForm at: 0@0
>
> 70% ==> image seg fault
> 30% ==> PrimitiveFailed: primitive #primSignal:andReturnAs:fromContext:
>
> but doing
> Smalltalk snapshot: true andQuit: true.
> surf := AthensCairoSurface extent: Display extent.
> Display getCanvas drawImage: surf asForm at: 0@0.
>
> 100% ==> PrimitiveFailed: primitive #primSignal:andReturnAs:fromContext:
>
>
> Evaluate the following in Playground for 100% segfault from command line.
>
> EllipseMorph compile: 'step
> |surf|
> [ surf := AthensCairoSurface extent: Display extent.
> Display getCanvas drawImage: surf asForm at: 0@0.
> ] on: Error do: [ ].
> self position: self position + (50@0). "To observe survival of seg fault" '.
> Smalltalk snapshot: true andQuit: true.
> EllipseMorph new openInWorld.
>
>
> btw, I'm on 32-bit Debian 8 Jessie
> $ uname -a
> Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux
>
> cheers -ben
>
>
> On Fri, Mar 3, 2017 at 12:08 AM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote:
> > Hi Eliot,
> >
> >
> >
> > Thanks to take care of this issue!
> >
> >
> >
> > Pavel opened a bug issue here:
> > https://pharo.fogbugz.com/f/cases/19785/Athens-crashes-the-VM . You need the
> > latest Pharo image and VM and it crashes under Linux (32-bit) and OSX (El
> > Captain, 32-bit VM). And I personally tried with Windows7 and the bug
> > happens too.
> >
> >
> >
> > To reproduce: Morph new testAthensRender
> >
> >
> >
> > An extract of the opened issue:
> >
> >
> >
> > Edited by Pavel Krivanek 02/03/2017 (Today) 16:10
> >
> > An empty surface crashes it too:
> > surf := AthensCairoSurface extent: Display extent.
> > Display getCanvas drawImage: surf asForm at: 0@0
> >
> >
> >
> > The problem is in the method AthensCairoSurface>>#asForm where the previous
> > slice started to add 1 to surface heigth
> >
> >
> >
> > Well, I tried to revert AthensCairoSurface>>#asForm which fixes this
> > particular case but Roassal still crashes on copyBits
> >
> >
> >
> > Cheers,
> >
> > Vincent
> >
> >
> >
> > De : Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] De la part de
> > Eliot Miranda
> > Envoyé : jeudi 2 mars 2017 17:03
> > À : Pharo Development List
> > Cc : Moose-related development; Squeak Virtual Machine Development
> > Discussion
> > Objet : [Moose-dev] Re: [Pharo-dev] Segmentation fault on Moose 6.1 Build
> >
> > Hi Vincent,
> >
> > first, apologies for the inconvenience, second, thanks! I badly need
> > reproducible failure cases to get the remaining bugs out of the compactor
> > and you have just provided me with one. Can you send me the information I
> > need to reproduce the build? What platforms does it fall on?
> >
> > On Thu, Mar 2, 2017 at 2:23 AM, Blondeau Vincent
> > <vincent.blondeau(a)worldline.com> wrote:
> >
> > Hi,
> >
> > The latest builds of the Moose6.1 image are failing due to a segmentation
> > fault.
> >
> > Here is the link to the last build:
> > https://ci.inria.fr/moose/job/moose-6.1/550/console
> >
> > How can we fix this?
>
--
www.tudorgirba.com
www.feenk.com
"Beauty is where we see it."
6 years, 6 months
How to know when a playground was executed and storing the result?
by Offray Vladimir Luna Cárdenas
Hi,
For the Grafoscopio notebook I would like to store the results of
playground executions. That would imply to know when a playground was
executed and which was the result[1]. We have been talking about that in
the Pharo users mailing list and Ben and Phill are bringing some light
on that, but I would like to invite Moose community to participate also.
I have been looking at some inspector and playground blog posts, but the
ones I have found are about creating custom views of objects you would
like to extend, instead of capturing the output.
[1]
http://forum.world.st/How-to-capture-the-execution-of-a-playground-tt4936...
There is any way to do that?
Offray
6 years, 6 months
Google Summer of Code 2017: Call for mentors for Pharo Consortium
by Serge Stinckwich
Heartiest Congratulations !
Pharo Consortium has been selected as a mentor organisation for Google
Summer of Code 2017.
Google Summer of Code is a global program focused on introducing
students to open source software development.
Students work on a 3 month programming project with an open source
organisation during their break from university. Read more at
https://summerofcode.withgoogle.com/
How the program works ?
Organizations:
Open source projects apply to be mentor organizations. Once accepted,
organizations discuss possible ideas with students and then decide on
the proposals they wish to mentor for the summer. They provide mentors
to help guide each student through the program.
Mentors:
Existing contributors with the organizations can choose to mentor a
student project. Mentors and students work together to determine
appropriate milestones and requirements for the summer. Mentor
interaction is a vital part of the program. A mentor may propose or
endorse a project and each project has to be about Pharo or its
ecosystem (e.g., a library). Projects will be mentored by one or more
mentors and executed by one student.
Students:
Students contact the mentor organizations they want to work with and
write up a project proposal for the summer. If accepted, students
spend a month integrating with their organizations prior to the start
of coding. Students then have three months to code, meeting the
deadlines agreed upon with their mentors. Student coding period: May
30 - Aug 29 (Entire timeline can be viewed at:
https://summerofcode.withgoogle.com/how-it-works/#timeline). Student
stipend: https://developers.google.com/open-source/gsoc/help/student-stipends
We are currently at the phase of identifying mentors and projects. The
next phases will be about students selecting projects, and the
community selecting the projects with their associated mentors and
students which will be sponsored by the GSOC program.
How to register ?
Simply by replying to this email and joining the Slack channel... to
have more discussion about what project the mentor will take up, what
she/he wants at the end of the coding period and then we can invite
them to the GSoC org dashboard).
Hence, we invite regular & enthusiastic Pharo contributors to be a
mentor with Pharo Consortium for GSoC 2017:
1. Kindly respond on this thread if you'd like to be a mentor, or wish
to propose a project.
An existing list of projects is already available here:
http://gsoc.pharo.org/ and we already have a handful of projects and
mentors chosen. Feel free to collaborate with existing mentors as
well.
2. Join dedicated channels, #gsoc-students for general interactions
with students & #gsoc-planning channel only for GSOC admins and
mentors on Pharo slack. In order to get an invitation for
pharoproject.slack.com visit the URL here:
http://slackinvites.pharo.org/
3. Please open relevant issues and make a roadmap of the projects
being mentored by you so that students can start contributing to them
already. If you want to mentor a project and there is no open-source
repository at the moment, please built one ASAP.
4. If you know any students that might be interested to work on Pharo
during the summer and be a part of GSoC as well, please ask him/her to
start contributing to the Pharo projects, discuss their proposal,
follow instructions that shall be posted soon in this mailing thread
and submit their application by April 3, 2017.
We don't know the number of slots attributed by Google to Pharo org,
but the more students proposal we will receive, the more slots will be
attributed to us.
We remind you about the mentor responsibilities:
... to your Org Admins
- Communicate availability and interaction expectations
- Inform when mentoring capacity will be reduced, as early as possible
(e.g., family, health, vacation)
- Inform when there is an issue with a student
- Lacking communication, activity, visibility (MIA), or progress
- Participant Agreement violations (e.g., plagiarism, harassment, fraud)
- Bad fit or stepping down
- Formally evaluate student participation.
- Communicate with admin and student before failing
... to your Students
- Help and/or teach the student
- how to be a part of your community
- communicate more effectively and in the open
- work with your org’s preferred communication channel (IRC, Slack, etc)
- use your org’s version control system
- ask good questions and get answers to their questions
- provide convincing technical argument and constructive discussion
- be independently motivated and productive
- solve difficult technical problems
- Keep track of their progress, keep student informed as to their status
- Communicate on a regular basis, once a week or better (for GSoC)
- Give constructive feedback, be patient, and be respectful
- Respond to questions within 24 hours (occasionally under 36 hours is ok)
- Establish realistic work objectives and timeline expectations
- Re-evaluate scope with student when significantly ahead of or behind
expectations
- Work with devs and community to facilitate acceptance of student work
Read more about responsibilities here:
https://developers.google.com/open-source/gsoc/help/responsibilities
Looking forward to a great guided summer by the talented mentors of
our organisation.
Warm Regards
Pharo Organisation Admins
(Alexandre Bergel, Jigyasa Grover, Serge Stinckwich & Yuriy Tymchuk)
6 years, 6 months
[Moose-dev] Student of Stéphane Ducasse: Roassal project
by said yebbah
Hello,
We‘re a group of 3 students from a course with Stéphane Ducasse in university of Lille 1,
and we’re beginners in Pharo and for the next 2 weeks we have to work on an open source project.
we choose Roassal project. So we would like to know what's the prupose of ideas that we've to do ?
In fact, in the moments we're at the point of discovering Roassal.
Thanks,
6 years, 6 months
