October 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] FOSDEM 2016 devroom selection

by Alexandre Bergel

Not be discouraged! Go go go! Alexandre > On Oct 23, 2015, at 11:58 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 23/10/15 12:07, Jose San Leandro wrote: >> Sad news. > > Indeed. I'll try again next year. > There are of course several devrooms where we can propose talks, e.g. > "Containers and Process Isolation" should be interested to hear about our long-time experience with images > > Stephan > > https://fosdem.org/2016/news/2015-10-22-accepted-devrooms/ > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 23, 2015

Re: [Pharo-users] Fwd: FOSDEM 2016 devroom selection

by Stephan Eggermont

On 23/10/15 12:07, Jose San Leandro wrote: > Sad news. Indeed. I'll try again next year. There are of course several devrooms where we can propose talks, e.g. "Containers and Process Isolation" should be interested to hear about our long-time experience with images Stephan https://fosdem.org/2016/news/2015-10-22-accepted-devrooms/

Oct. 23, 2015

Re: [Pharo-users] VM crash on Ubuntu 14.04

by Ben Coman

On Thu, Oct 22, 2015 at 2:25 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Hi all, > > I am having some unpleasant experiences on Ubuntu 14.04 (experimenting with Live Robot Programming on PhaROS). The VM crashes after a random amount of time (< 25 minutes), with no clear sequence of steps on how to reproduce the crash. I am using Pharo 4 (Pharo 40622 as installed by PhaROS) + Roassal which required an install of libcairo2:i386 . VM version details below. > > There is no printout on stdout, and the debug.log does not contain recent entries (timestamp is always some minutes before the actual crash happens). > > Is this a known problem? If so, how can I fix it, and if not how can I provide more debugging info? > > Thanks in advance! I'm not much help since I haven't done these myself, but just some ideas (maybe someone can add more details) * compile and run a debug vm * trace all function calls, http://tinyurl.com/gdb-trace-all cheers -ben > vm version: > 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-484 > 1-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2 > 975997bba66 May 15 2014 > https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406 > f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm@ > gmail.com> Jenkins build #14826 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 201 > 2 i686 i686 i386 GNU/Linux > plugin path: /home/jfabry/catkin_ws/src/pharo/vm/ [default: /home/jfabry/catkin_ > ws/src/pharo/vm/] > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > >

Oct. 23, 2015

Re: [Pharo-users] memory question

by Alexandre Bergel

Well, this is not enough. This #sizeInMemory only tells you the size of the object, which is simply the number of variables * 4 + size of the header. For collection, such as OrderedCollection and Dictionary, it is worth asking #size and #capacity: - #size tells you the amount of objects kept in the collection - #capacity tells you the maximum size the collection can hold without triggering a grow operation. For example: Dictionary new sizeInMemory => 16 d := Dictionary new. d at: #foo put: 1. d sizeInMemory => 16 d := Dictionary new. d at: #foo put: 1. d capacity => 5 d := Dictionary new. 1 to: 1000 do: [ :i | d at: i put: i ]. d capacity => 2213 d := Dictionary new. 1 to: 1000 do: [ :i | d at: i put: i ]. d size => 1000 Alexandre > On Oct 23, 2015, at 9:06 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 23.10.2015 um 13:29 schrieb Werner Kassens <wkassens(a)libello.com>: >> >> sorry, wrong thread, that was unintentional. werner >> >> On 10/23/2015 01:24 PM, Werner Kassens wrote: >>> Hi, >>> i'd like to test how much memory a dictionary uses. i guess i could >>> simply delete that dictionary and see how much memory the garbage >>> collector releases, but i wonder how i could measure that without >>> destroying that dictionary? >>> werner > > Try > > Dictionary new sizeInMemory > > Norbert > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 23, 2015

Re: [Pharo-users] memory question

by Norbert Hartl

> Am 23.10.2015 um 13:29 schrieb Werner Kassens <wkassens(a)libello.com>: > > sorry, wrong thread, that was unintentional. werner > > On 10/23/2015 01:24 PM, Werner Kassens wrote: >> Hi, >> i'd like to test how much memory a dictionary uses. i guess i could >> simply delete that dictionary and see how much memory the garbage >> collector releases, but i wonder how i could measure that without >> destroying that dictionary? >> werner Try Dictionary new sizeInMemory Norbert

Oct. 23, 2015

Re: [Pharo-users] Feedback on #assert: vs. #assert:equals:

by Nahuel Garbezza

Thanks for the answers, and for addressing this soon :) I would like to participate on the sprint but I can't make it this time. Nahuel 2015-10-22 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Dear Nahuel, > > I think you are raising in excellent point. > I think that assert: should raise an assertion error when a non-boolean is > provided. > I have added an entry: > https://pharo.fogbugz.com/f/cases/16847/assert-should-not-raise-an-error-wi… > > Tomorrow we have a sprint, this is like an easy thing to fix. We will work > on it! > > Thanks, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Oct 21, 2015, at 10:21 PM, Nahuel Garbezza <n.garbezza(a)gmail.com> wrote: > > Hi everyone, > > I'm using Pharo for teaching and we use TDD since the beginning. I've > noticed that if you use #assert: on a test, like this: > > self assert: object messageReturningBoolean > > It gives you strange results in terms of feedback if the result is not a > boolean. I would expect an AssertionFailed (yellow test) but I got a > NonBooleanReceiver (red test). > > What we do in our course is to write the assertion like this: > > self assert: object messageReturningBoolean equals: true > > So we got a "expected true but was <other object>" error which is a lot more > helpful to the students. > > I was thinking that is better to have #assert: implementation based on > #assert:equals:. It is like saying #assert:equals: is the "primitive" > assertion message, which makes sense to me since you are always comparing if > an object is equal to another, there's no reason to handle the booleans' > case differently. > > What do you think? > > Thank you! > > Nahuel > >

Oct. 23, 2015

Re: [Pharo-users] memory question

by Werner Kassens

sorry, wrong thread, that was unintentional. werner On 10/23/2015 01:24 PM, Werner Kassens wrote: > Hi, > i'd like to test how much memory a dictionary uses. i guess i could > simply delete that dictionary and see how much memory the garbage > collector releases, but i wonder how i could measure that without > destroying that dictionary? > werner > >

Oct. 23, 2015

memory question

by Werner Kassens

Hi, i'd like to test how much memory a dictionary uses. i guess i could simply delete that dictionary and see how much memory the garbage collector releases, but i wonder how i could measure that without destroying that dictionary? werner

Oct. 23, 2015

Re: [Pharo-users] Fwd: FOSDEM 2016 devroom selection

by Jose San Leandro

Sad news. 2015-10-22 17:05 GMT+02:00 stephan <stephan(a)stack.nl>: > > -------- Forwarded Message -------- Subject: FOSDEM 2016 devroom selection Date: > Thu, 22 Oct 2015 13:18:25 +0200 From: Johan van Selst <johans(a)fosdem.org> > <johans(a)fosdem.org> To: devrooms(a)fosdem.org > > Hi, > > I'm sorry to inform you that we declined your devroom proposal. > > To clarify, your request was perfectly valid, but we had to choose. > Unfortunately we do not have a sufficient number of rooms at our > disposal to cover all requests. This year, we had over 60 requests > for a devroom and were only able to accept 37 of those. However, > some requests have been combined into a single devroom. > > Nevertheless, there are other ways to participate in FOSDEM too. > You can still: > - have a stand at FOSDEM, > - hold a 15 minute 'lightning talk' in one of the biggest rooms, > - speak in one of the other devrooms (CfP to follow), > - hold a session in the community meeting room (new; CfP to follow). > > The full list of accepted devrooms will be published on the > FOSDEM website later this week. > > > On behalf of the FOSDEM devroom team, > > Johan van Selst > > > > >

Oct. 23, 2015

Re: [Pharo-users] Updated Pharo By Example

by Damien Cassou

Dimitris Chloupis <kilon.alios(a)gmail.com> writes: > "Yes we can ask oscar and after will host it also at books.pharo.org and in > HTML version too as for all the other books. please contact "Oscar Nierstrasz" <oscar(a)iam.unibe.ch> to: - get the website sources - redirect pharobyexample.org to files.pharo.org/books/pharobyexample > "pay attention. I think that we should minimize UI elements and external > frameworks because else we will have more work in 4 years from now. " > > What do you mean ? Stephane wants to facilitate migration of UPBE to Pharo 6/7/8/... For that, the book should limit the number of screenshots and fine-grained tutorials such as "Left click Here, press the button name 'That Way', you will see a window looking like That". These fine-grained instructions are a pain to update and need to change with each version of Pharo. It is ok to have some, but not too much. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Oct. 23, 2015