March 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face

by stepharong

we were talking during the workshop and on the simple things to help. - watch points with history of the value. - stop if the value of an instance variable is getting irregular i.e., = you get integer and suddenly inside you get a float! 1 1 1 1 2 3 4 2 2 1 1 12 2 3 32 1 1 1 1 22 1 1 1 1 1 1 1 2 33 1.2 2 3 3 4 4 - start to monitor (put alarm/breakpoints) newly created instances from a point I hope that soon we will have instance specific features of the Ressia debugger in Pharo debuger (stop the next time this object receive a message, stop the next tie this object changes any of its instance variables).

March 9, 2017

implementors followed by rename method -> DNU

by stepharong

Hi I have the impression that if you - perform an implementor of a method (not closing the window) - then perform an rename method => you get a DNU ast Could I get some confirmation? Stef

March 9, 2017

Re: [Pharo-dev] What is the craziest bug you ever face

by Holger Freyther

> On 9 Mar 2017, at 12:36, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > During the DSU workshop we were brainstorming about what are the most difficult bugs we faced and what are the conceptual tools that would have helped you. Tracking down a problem where a header file was like this struct touch_screen_event { #ifdef SOME_FLAG ... other fields #endif int x; int y; int pressure; }; The touchscreen library was compile with -DSOME_FLAG but the code using that library didn't have the flag set. This means the code using the touchscreen events read x/y from the wrong offset in memory. The example work of the touchscreen library worked while the real user didn't. It would have helped to embed struct sizes and offsets into the shared library to find differences at link time. --- Keyboard handling in kdrive (an Xserver for embedded/mobile usage): After plugging/unplugging USB into the device, the keyboard started to generate wrong keycodes. In Linux (depending on your keyboard mode) every key event is represented as a byte(?). This worked for a long time but then keyboards started to have more keys. So a special key value is used to indicate that a multi byte sequence will follow. As it turns out plugging/unplugging generated a multi-byte keyboard event... Not sure what would have helped? :)

March 9, 2017

Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face

by stepharong

Thanks you all. The idea is that we want to see how we cn improve our debugging arsenal. So it is important that your scenario give use some hints. It is difficult to convey what we are really looking for :) > Hi guys > > During the DSU workshop we were brainstorming about what are the most > difficult bugs we faced and what are the conceptual tools that would > have helped you. > > Stef -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-dev] ExternalForm was removed 10 days ago in 60413

by stepharong

super! On Thu, 09 Mar 2017 18:56:00 +0100, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, I will move to his own package > >> On 9 Mar 2017, at 18:52, stepharong <stepharong(a)free.fr> wrote: >> >> esteban >> >> I have the impression that externalForm should be independent of >> OSWindows. >> >> stef >> On Thu, 09 Mar 2017 12:15:54 +0100, Esteban Lorenzano >> <estebanlm(a)gmail.com> wrote: >> >>> wellâ¦ it was removed and I put it on OSWindows-SDL2 because it was the >>> only place where it was being used. >>> We can move it again to a more general place (Like UnifiedFFIâ¦ or itâs >>> own). >>> >>> Esteban >>> >>>> On 9 Mar 2017, at 11:54, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>>> >>>> ... and was moved to OSWindow-SDL2 as OSSDL2ExternalForm. >>>> >>>> If we require external form but don't want to depend on OSWindow what >>>> is the right way to go? Do we need to copy OSSDL2ExternalForm with >>>> project specific name? >>>> >>>> Advice with best practice would be nice :) >>>> >>>> Cheers, >>>> Alex >>> >>> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ > -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face

by Igor Stasenko

I don't think my reply will be anything useful, but as to me the most craziest bug is metabug, i.e. when system doesn't provides any means to debug things. :) As for regular bugs .. it is quite hard to remember anything i wasn't able to deal with, given enough time & effort, and then emphasize single case over the rest. And since human brains tend to forget unpleasant things, there's not much details to tell and remember. On 9 March 2017 at 13:36, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys > > During the DSU workshop we were brainstorming about what are the most > difficult bugs we faced and what are the conceptual tools that would have > helped you. > > Stef > -- Best regards, Igor Stasenko.

March 9, 2017

Re: [Pharo-dev] ExternalForm was removed 10 days ago in 60413

by Esteban Lorenzano

yes, I will move to his own package > On 9 Mar 2017, at 18:52, stepharong <stepharong(a)free.fr> wrote: > > esteban > > I have the impression that externalForm should be independent of OSWindows. > > stef > On Thu, 09 Mar 2017 12:15:54 +0100, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> wellâ¦ it was removed and I put it on OSWindows-SDL2 because it was the only place where it was being used. >> We can move it again to a more general place (Like UnifiedFFIâ¦ or itâs own). >> >> Esteban >> >>> On 9 Mar 2017, at 11:54, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>> >>> ... and was moved to OSWindow-SDL2 as OSSDL2ExternalForm. >>> >>> If we require external form but don't want to depend on OSWindow what is the right way to go? Do we need to copy OSSDL2ExternalForm with project specific name? >>> >>> Advice with best practice would be nice :) >>> >>> Cheers, >>> Alex >> >> > > > -- > Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-dev] ExternalForm was removed 10 days ago in 60413

by stepharong

esteban I have the impression that externalForm should be independent of OSWindows. stef On Thu, 09 Mar 2017 12:15:54 +0100, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > wellâ¦ it was removed and I put it on OSWindows-SDL2 because it was the > only place where it was being used. > We can move it again to a more general place (Like UnifiedFFIâ¦ or itâs > own). > > Esteban > >> On 9 Mar 2017, at 11:54, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> ... and was moved to OSWindow-SDL2 as OSSDL2ExternalForm. >> >> If we require external form but don't want to depend on OSWindow what >> is the right way to go? Do we need to copy OSSDL2ExternalForm with >> project specific name? >> >> Advice with best practice would be nice :) >> >> Cheers, >> Alex > > -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Segmentation fault on Moose 6.1 Build

by Martin Dias

Related: https://pharo.fogbugz.com/f/cases/19820/Epicea-GrafPort-error-when-open-bro… On Fri, Mar 3, 2017 at 3:17 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > The build is now green. > > Did anyone else encounter problems with the new code when playing with > Roassal? > > Cheers, > Doru > > > > > On Mar 3, 2017, at 11:39 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > The integration took a wrong slice... > > > > 2017-03-03 10:34 GMT+01:00 Blondeau Vincent <vincent.blondeau@worldline. > com>: > > Nice try, but it doesn't seems to :( : > > https://ci.inria.fr/moose/job/moose-6.1/556/console > > > > Smalltalk stack dump: > > 0xbfc61c50 I GrafPort>copyBits 0x9c1f7a8: a(n) GrafPort > > 0xbfc61c70 I GrafPort>image:at:sourceRect:rule: 0x9c1f7a8: a(n) GrafPort > > 0xbfc61ca0 I FormCanvas>image:at:sourceRect:rule: 0x9c12a98: a(n) > FormCanvas > > > > Cheers, > > Vincent > > > > > > > -----Message d'origine----- > > > De : Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] De la > part de > > > Tudor Girba > > > EnvoyÃ© : vendredi 3 mars 2017 10:22 > > > Ã : Pharo Development List > > > Cc : Moose-related development > > > Objet : [Moose-dev] Re: [Pharo-dev] Re: Segmentation fault on Moose 6.1 > > > Build > > > > > > 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." > > > > > > > > > > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > Moose-dev(a)list.inf.unibe.ch > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > !!!********************************************************* > **************************** > > "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.!!!" > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

March 9, 2017

Re: [Pharo-dev] Archive Page for Pharo TechTalks

by stepharong

excellent!!!! On Thu, 09 Mar 2017 11:02:59 +0100, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, I added http://pharo.org/TechTalk This is linked from > http://pharo.org/community The idea is to keep a log of all past tech > talks with links to the archival recording (if there is one). >Marcus -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017