- Pharo-users - lists.pharo.org

Re: [Pharo-users] Ring question

by Marcus Denker

Hello, I think the RBContainer has not seen to much use until now. In general, Ring was a bit too designed for flexibility that I guess was good in the past, but not needed now. E.g. it used to create every Ring entity via a factory. I started to simplify it a lot in Pharo5. This removed lots of code and even made things faster. With the âRemote Developmentâ project starting soon, we will do another pass over Ring, I think. We need to especially unify the âEnvironmentâ concepts of RB, the system and Ring. Marcus > On 02 Nov 2015, at 10:14, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > I'm trying to look into Ring implementation. > > So I have a first question. Why is RGAbstractContainer and subclasses irregular? Is that on purpose? > > Details: RGAbstractContainer delegates adding a new element to the element being added, via aRGElement>>#addInContainer:. This element is then expected to use RGContainer>>#addTrait:/#addPackage:/#addMethod: etc... However only a subset of the RGElements implement #addInContainer:; for example, RGTrait does not implement #addInContainer: (*). > > (*) Ok, RGContainer>>#addTrait: calls RGContainer>>#addClass:, and RGTrait being a subclass of RGBehaviorDefinition, that works. But I'm still ?? > > Thierry

Nov. 2, 2015

Ring question

by Thierry Goubier

I'm trying to look into Ring implementation. So I have a first question. Why is RGAbstractContainer and subclasses irregular? Is that on purpose? Details: RGAbstractContainer delegates adding a new element to the element being added, via aRGElement>>#addInContainer:. This element is then expected to use RGContainer>>#addTrait:/#addPackage:/#addMethod: etc... However only a subset of the RGElements implement #addInContainer:; for example, RGTrait does not implement #addInContainer: (*). (*) Ok, RGContainer>>#addTrait: calls RGContainer>>#addClass:, and RGTrait being a subclass of RGBehaviorDefinition, that works. But I'm still ?? Thierry

Nov. 2, 2015

Re: [Pharo-users] Multiple method deletion

by stepharo

I have to think a bit (and read some code :). Stef Le 29/10/15 09:48, Ferlicot D. Cyril a Ã©crit : > Le 29/10/2015 16:33, stepharo a Ã©crit : >> Excellent news! >> >>> Hi, >>> >>> I think I found how to reproduce it: >>> >>> https://pharo.fogbugz.com/f/cases/16891/FT-Multi-selection-can-happen-when-… >>> >>> >>> I think this is a FastTable problem with Nautilus. >>> >> > The problem is that when we try to remove something, the MethodsWidget > give the selected methods. > These methods are store inside an identityDictonary with the > CompiledMethod as key and a boolean as value. > > Usually that works but when we compile a method a new instance of > CompiledMethod is store on the dictionary. So with the identity > dictionary we now have two elements for the same method since the > pointers are not the same. > > Does someone know if it is important that the selected methods of the > MethodWidget are store on an IdentityDictionary and not in a Dictionary ? > > If this is not important we can change it, else at the compilation we > will need to remove this method from the IdentityDictionary. >

Nov. 2, 2015

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

by Johan Fabry

Whoa guys, sorry for all this but there is some miscommunication going on here. Steph was replying now to an old mail of mine. I said that because for a number of days I had no replies to my initial report. So *at that time* no VM guys were following up on this and I was lost and helpless. I donât know anything about building VMâs and nothing about how to debug them. This is clearly no longer the case. I have had a lot of help this week and I *do* appreciate the feedback you guys have been giving me! I know I am not giving a lot of useful information but the setup is complicated, and I have extremely limited knowledge about how to debug native apps in Linux. So I am doing all that I can and I am happy to receive whatever pointers may be useful. We will investigate more with Ronie this week I am sure that with his help we will move forward much more smoothly. > On Nov 1, 2015, at 08:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> Ben, thanks for replying but since no VM guys are following up on this, apparently, it does not make much sense for me to go this way. > > Yep, that hurts. > >> Guys, am I to assume there is not help for me on this topic? > > And that hurts even more. > > Iâm *trying* to help you, but so far you provided almost none information (is like going to the doctor and say âI feel badâ). > Even without information I told you âis the heapâ. Now I will told you something more: a debug vm will not help you much because you are running out of resources *in the HEAP*. > > try expanding memory and monitoring memory consumption to see how it goes. > try forcing free of resources in your visualisations or anything âFFI Relatedâ. > > cheers, > Esteban > > ps: And yes, we need to update the âdebug vm buildâ info in the instructions, but is just affecting on line or so :) > pps: And we also could provide some debug vms for this cases. I cannot schedule the time now for doing the jobs, but I will put it in my TODO list. > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Nov. 1, 2015

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

by Esteban Lorenzano

> Ben, thanks for replying but since no VM guys are following up on this, apparently, it does not make much sense for me to go this way. Yep, that hurts. > Guys, am I to assume there is not help for me on this topic? And that hurts even more. Iâm *trying* to help you, but so far you provided almost none information (is like going to the doctor and say âI feel badâ). Even without information I told you âis the heapâ. Now I will told you something more: a debug vm will not help you much because you are running out of resources *in the HEAP*. try expanding memory and monitoring memory consumption to see how it goes. try forcing free of resources in your visualisations or anything âFFI Relatedâ. cheers, Esteban ps: And yes, we need to update the âdebug vm buildâ info in the instructions, but is just affecting on line or so :) pps: And we also could provide some debug vms for this cases. I cannot schedule the time now for doing the jobs, but I will put it in my TODO list.

Nov. 1, 2015

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

by Ben Coman

On Fri, Oct 30, 2015 at 2:03 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > OK, back with access to the Ubuntu machine, I reproduced the crash when > running under gdb (reproducing it is never an issue, finding the minimal > case is the issue). See below for gdb output. But my vm has no debug > information compiled, so it is not really useful. Can I download a vm with > debug info compiled from somewhere? I would prefer to avoid having to > download the sources and compile et cetera â¦ Why not give it a go? :) I found it dead simple to compile the VM for the first time following instructions at... [1] https://github.com/pharo-project/pharo-vm This was on OSX and the only problem I had was _not_ following the instructions and using XCode 10.9 instead of 10.6. I can't speak for Ubuntu but its the reference Unix platform. I guess you'll get better support getting started with the standard instructions (since we'd like them "perfect" and more people will be able to replicate a problem with these than replicate your unique problem) One thing though, could someone update [1] to describe how to get a debug VM, since that must be a common reason someone wants to compile their own VM for the first time. I hunted around for some info but could only find tips from a few years ago and I'm not sure if they still apply Debug a VM (by Mariano) https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-u… https://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/ https://vimeo.com/22485382 (PharoCast) Debugging assembly in Pharo VM with GDB (by Melkyades) http://melkyades.blogspot.com.au/2013/07/debugging-assembly-in-pharo-vm-wit… cheers -ben > > Once I have such a VM I will make some time to further investigate, and > report results. > > Program received signal SIGSEGV, Segmentation fault. > 0xb8c2bc31 in ?? () > (gdb) bt > #0 0xb8c2bc31 in ?? () > #1 0x080fc9f2 in primitiveNativeCall () > #2 0xb4fba770 in ?? () > #3 0xb503b05e in ?? () > #4 0xb503afcb in ?? () > #5 0xb5011abd in ?? () > #6 0xb4fba5c0 in ?? () > (gdb) > > On Oct 27, 2015, at 19:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-10-26 15:03 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: >> >> Hi Nicolai, >> >> thanks for following up on this. >> >> I am in the process of determining what causes the crash. I fear that to >> reproduce the problem you will need to have ROS installed, I have not yet >> been able to reproduce it without ROS running. I do not want to inflict the >> installation of ROS on you without being 100% sure. >> >> I am using Roassal because this is for Live Robot Programming >> (http://pleiad.cl/LRP) which uses a dynamic visualization of the running >> code. To reproduce the bug (until now) I need to develop code in LRP when >> using ROS, and then it happens randomly. I realize that this is too much to >> ask for an outsider to reproduce the bug (I did not expect anybody to >> download and install PhaROS to try to reproduce, thanks for that!!). >> >> Can you inform me how I can get you more useful debug info to you? I will >> keep trying to find minimal steps to reproduce in the mean time. > > > No, the best we can hope for is a crash when it is running from debugger, > you can start the vm with a debugger or attach the debugger to a running > process. If we are lucky, the debugger will show a stacktrace. > >> >> >> On Oct 24, 2015, at 19:45, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> Can you provide the image file. >> What exactly runs in the image (does it depend on ROS or >> does it crash even without it). For what do you >> use Roassal in this environment. >> Can you reproduce the crash with a clean image (and maybe loading >> some package - without all of the ROS-stuff? >> (I just followed the installation guide for PhaROS, but I have no idea >> how to go from here to do anything to reproduce the crash). >> >> >> >> 2015-10-24 21:32 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: >>> >>> >>> Ben, thanks for replying but since no VM guys are following up on this, >>> apparently, it does not make much sense for me to go this way. >>> >>> Guys, am I to assume there is not help for me on this topic? >>> >>> > On Oct 23, 2015, at 11:03, Ben Coman <btc(a)openInWorld.com> wrote: >>> > >>> > 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 >>> > >>> >>> >>> >>> ---> Save our in-boxes! http://emailcharter.org <--- >>> >>> Johan Fabry - http://pleiad.cl/~jfabry >>> PLEIAD and RyCh labs - Computer Science Department (DCC) - University >>> of Chile >>> >>> >> >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University >> of Chile > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of > Chile >

Nov. 1, 2015

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

by Ronie Salgado

Hi Johan, Perhaps I can try to help you debugging with gdb. Are you using a 32 bits or 64 bits Ubuntu ? We should start by building a debug Pharo VM. Do you have some time during Monday or Wednesday in your office?. Greetings, Ronie 2015-10-31 22:00 GMT-03:00 stepharo <stepharo(a)free.fr>: > Why do you say that johan? > Everybody is busy and has its own agenda. I'm sure that esteban would love > to have the time > to just wait for helping people. This is not the case and the dragons he > is fighting against are > quite large and venomous. > So the suggestion of Ben is good because else I do not see how people can > help you. > > Stef > > Le 24/10/15 12:32, Johan Fabry a Ã©crit : > > Ben, thanks for replying but since no VM guys are following up on this, >> apparently, it does not make much sense for me to go this way. >> >> Guys, am I to assume there is not help for me on this topic? >> >> On Oct 23, 2015, at 11:03, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> 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 >>> >>> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University >> of Chile >> >> >> >> > >

Nov. 1, 2015

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

by stepharo

Why do you say that johan? Everybody is busy and has its own agenda. I'm sure that esteban would love to have the time to just wait for helping people. This is not the case and the dragons he is fighting against are quite large and venomous. So the suggestion of Ben is good because else I do not see how people can help you. Stef Le 24/10/15 12:32, Johan Fabry a Ã©crit : > Ben, thanks for replying but since no VM guys are following up on this, apparently, it does not make much sense for me to go this way. > > Guys, am I to assume there is not help for me on this topic? > >> On Oct 23, 2015, at 11:03, Ben Coman <btc(a)openInWorld.com> wrote: >> >> 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 >> > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > >

Nov. 1, 2015

Re: [Pharo-users] [ANN] Working with Pharo on the Raspberry Pi

by stepharo

Jean-Baptiste did it and demoed it at ESUG at Cambridge. He is now travelling and crashed his machine so may contact him at: jbaptiste.arnaud(a)gmail.com He will be probably busy until wednesday fixing his machine and application to a new job. Stef Le 30/10/15 08:27, Tim Hendriks a Ã©crit : > What I would like is access to the GPIO pins from Pharoâ¦. It is possible from Scratch so someone (i am to stupid to do this) could maybe hack that into Pharo? > > Tim > > >> On 30 Oct 2015, at 16:22, Tim Hendriks <th72(a)dds.nl> wrote: >> >> Pharo5 works with fine with the squeak vm in Jessie. No errorâs and much faster. Didnât test it thoroughly. >> >> Tim >> >> >>> On 26 Oct 2015, at 16:41, Attila Magyar <m.magyar3(a)gmail.com> wrote: >>> >>> Hi Torsten, >>> >>> Have you tried the cogvm on the Pi? It is much faster than the stack vm. If >>> I remember correctly, I used this one last time: >>> http://www.mirandabanda.org/files/Cog/VM/VM.r3427/cogspurlinuxhtARM-15.33.3… >>> >>> Attila >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/ANN-Working-with-Pharo-on-the-Raspberry-Pi-tp4857895p… >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >> > >

Nov. 1, 2015

[ANN] RenoirSt 2.0.0 released!

by Gabriel Cotelli

Hi, I'm announcing a new official release of RenoirSt. See the announcement and changelog <https://plus.google.com/111529669851117270585/posts/AxCpTvnhhAb> Regarsd, Gabriel

Oct. 31, 2015