- Pharo-dev - lists.pharo.org

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

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

by Ron Teitelbaum

We had to fix a Heisenbug. (a bug that never breaks when you look at it) This was a bug that happened only in production, didn't break every time, and never broke while debugging. It also got less frequent the more we added logging to report on the current state when the bug happened. We knew it was a timing issue but exactly what was happening eluded us. The trick eventual was logging. We kept adding and removing logging and mapping the state during the bug until we understood it on paper. Then we created a test that reproduced it, fixed it, and celebrated! It was really difficult! The lesson is that no matter how difficult or infrequent the bug occurs with enough persistence and hard work you can figure it out! All the best, Ron Teitelbaum www.3dicc.com On Thu, Mar 9, 2017 at 9:38 AM Max Leske <maxleske(a)gmail.com> wrote: > Fixing a race condition in handling open sockets when forking an image. At > first I had no clue where the problem could come from, then I spent a lot > of time guessing at the conditions (of course, being a race condition there > was no means to force the specific condition but I didn't know that yet). > > Over all I spent about 6 weeks on this bug and finally fixed it by > creating a new primitive to handle that specific case. I'm not sure what > tools could have helped me as this was a rather specific problem > (OSProcess). But the hardest problems in my experience are usually > concurrency / asynchrony (e.g. race conditions) or bugs in libraries (where > you always assume that you must have made a mistake, never the library). > > Max > > > 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. > > > > Stef > > > >

March 9, 2017

Re: [Pharo-dev] Catalog projects in Spotter

by Yuriy Tymchuk

Hi, yes, I know that the Spotter checkbox is a generic implementation and it is really cool. My point(s) is (are): 1) why are the checkboxes out of sync? When I added a checkbox to disable the QA Spotter plugin from within the QA settings, I reused spotters functionality, so enabling or disabling with change the status of both checkboxes and you donât have to enable the functionality twice. 2) why are there 2 checkboxes? Because Esteban told me that it is confusing that when you search for critiques in settings you get duplicated results. Thatâs why I removed my other checkbox and rely only on Spotter settings. If there is a rule not to duplicate preferences, why is catalog not following it? Uko > On 9 Mar 2017, at 15:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Mar 9, 2017, at 3:22 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> Yes, you are right Sven. >> >> When I disable network the Spotter is not freezing. Do we have a way to do the DNS resolution asynchronously? I mean, is it doable in Pharo 7 or it is a big problem. Iâm not an expert in the questions that require VM, but it seams that http requests can be executed without blocking the UI thread, is it possible to resolve DNS in the same way? >> >> Uko >> >> P.S. why there are TWO checkboxes in Settings for the catalog plugin in Spotter? And they are not synchronized by the way, so you need to turn on both. > > Each spotter extension comes with checkbox to disable them. This is a generic mechanism that is important for cases when people want to replace an existing extension with another variation. For example, people might have different preferred strategies to search for implementors (e.g., also search for class names). > > Cheers, > Doru > > >> >> >>> On 9 Mar 2017, at 09:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Guys, >>> >>> Please stop speculating, no it is not Monticello, no it is not HTTP access, no it is not networking itself, it is DNS resolution, in a very specific situation: >>> >>> https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForNam… >>> >>> Note also that many, many people deploy Pharo in production contexts with heavy multi threading and networking loads with great success - that would not be possible if we did not get the basics right. >>> >>> Sven >>> >>>> On 9 Mar 2017, at 09:31, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> Dimitris, >>>> >>>> but AFAIK when Spotter freezes itâs not using Metacello. It does an http request to pharo catalog. Isnât this a problem with http request blocking the only thread that we have? >>>> >>>> Uko >>>> >>>>> On 9 Mar 2017, at 08:23, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>>> >>>>> I do not need to, the problem is obvious as the sun when one uses Monticello which can easily freeze the image on a slow connection. Still it's a Monticello problem, not a Pharo problem. But then that's not the most serious problem with Monticello. >>>>> >>>>> On Tue, 7 Mar 2017 at 17:04, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>> I see you are not teaching to people or running demos in a crowd with Pharo. >>>>> >>>>> Otherwise, you would get the point I can tell you 100% >>>>> >>>>> Phil >>>>> >>>>> On Tue, Mar 7, 2017 at 3:19 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>>> Frankly I fail to see the problem, if a tool connects to the internet and does not have some sort of timeout or speed check then is the obligation of the tool to fix that and not of Pharo to offer an airplane mode. Its would make an already complex pharo environment even more complex. Not to exclude the fact that having two mode will create useless confusion for beginners. >>>>> >>>>> Offer a new mode for Pharo ? No >>>>> Offer methods that check internet connectivity and internet speed for pharo tool developers to use ? Yes >>>>> >>>>> I feel that Pharo can be simplified down to 1% without the need for a big compromise on features. Maybe it does not matter for us that are used to working with Blender but its a huge deal for beginners and if we want to attract a lot more new users. >>>>> >>>>> My dream is that version 8 be dedicated ONLY to simplifying the Pharo code, by removing all the extra fat. No new bug fixes (unless created by the removal of the code), no new features. I know we have bootstrap , but thats a completely different thing. >>>>> >>>>> On Tue, Mar 7, 2017 at 3:15 PM phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>> https://pharo.fogbugz.com/f/cases/19818/Support-for-Airplane-mode-in-Pharo for keeping track of this >>>>> >>>>> On Tue, Mar 7, 2017 at 1:02 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>>> On Tue, Mar 7, 2017 at 6:35 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>>> This is not only when teaching. >>>>>> >>>>>> I was at a conference today and showcased some Grafoscopio. >>>>>> >>>>>> Spotty wifi and crowded bandwith makes it bad looking. >>>>>> >>>>>> We need an "Airplane mode" switch. >>>>> >>>>> That is a cool way to describe it. A well know paradigm. >>>>> Its a setting that probably would change daya to day more than any other, >>>>> so perhaps it would even be reasonable to have this as a permanent >>>>> mode button on the background, >>>>> or the task bar much like MS Windows taskbar status icons. >>>>> >>>>> cheers -ben >>>>> >>>>>> >>>>>> Maybe can we have that available in the session from the settings. >>>>>> >>>>>> Phil >>>>>> >>>>>> On Mon, Mar 6, 2017 at 10:55 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>>>> >>>>>>> The problem is that there are people who give lectures in universities >>>>>>> with bad internet (internet is bad in most of the universities I tried) and >>>>>>> they done want freezes. On the other hand we have people who sit in their >>>>>>> offices with fast machines, fast internet and they want features. Until now >>>>>>> we were looking at how to satisfy one of the groups and which one exactly. >>>>>>> Why not to try finding a solution for both. For example we can have the >>>>>>> plugging enabled by default and have Spotter measuring the time needed to do >>>>>>> a query. Whenever the time surpasses frustration limit (10 sec? I duno) >>>>>>> Spotter will ask if the user wants to turn off the plugin, of turns it of >>>>>>> automatically and tells where to re-enable it. The other way would be to >>>>>>> have known plugins to appear at the bottom of Spotter, and a user can >>>>>>> install/enable them with one click. So when you search but there is nothing >>>>>>> you know that there are more plugins that may solve your problem. >>>>>>> >>>>>>> Yes it is more complicated to implement in in a smart way rather them just >>>>>>> set the default boolean value of a setting, but we spend too much time >>>>>>> anyway convincing the other side that we are rightâ¦ >>>>>>> >>>>>>> Uko >>>>>>> >>>>>>>> On 6 Mar 2017, at 21:30, stepharong <stepharong(a)free.fr> wrote: >>>>>>>> >>>>>>>> One day I would like to invite you to give a lecture in a not that bad >>>>>>>> french university >>>>>>>> with a not that good network. Each time Pharo freezes you pay me 5 Euros >>>>>>>> only and we can >>>>>>>> go and pay some really expensive restaurant with your money. >>>>>>>> Simple on my machine it times out every five minutes. >>>>>>>> >>>>>>>> <sorry I could not resist> >>>>>>>> >>>>>>>>> >>>>>>>>>> On 6 Mar 2017, at 19:51, stepharong <stepharong(a)free.fr> wrote: >>>>>>>>>> >>>>>>>>>> We should make it available from the catalog :) >>>>>>>>> >>>>>>>>> Yes, it most certainly should be. >>>>>>>>> >>>>>>>>> If only we could then tell user to type >>>>>>>>> >>>>>>>>> Shift-Enter Sublimish Enter >>>>>>>>> >>>>>>>>> to install it using Spotter right from the catalog ;-) >>>>>>>>> >>>>>>>>> Sorry, I couldn't resist ... <ducking> >>>>>>>>> >>>>>>>>>> 2017-03-06 9:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>>>>> >>>>>>>>>>> On 6 Mar 2017, at 09:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-03-06 8:20 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> On 6 Mar 2017, at 07:57, phil(a)highoctane.be wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator-simple/7294/artifac… >>>>>>>>>>>> is not integrated for some Monkey reason anyway - still should b/c if you >>>>>>>>>>>> put sublimish, you need a decent matching Spotter. >>>>>>>>>>>> >>>>>>>>>>>> Also, I see >>>>>>>>>>>> https://pharo.fogbugz.com/f/cases/19796/Remove-duplicate-code-from-Sublimis… >>>>>>>>>>>> on 5/3. If this moves forward, why not the other one? >>>>>>>>>>>> >>>>>>>>>>>> BTW Sublimish was an extra thing. Who got that in image? >>>>>>>>>>> >>>>>>>>>>> I donât know. >>>>>>>>>>> It shouldnât :) >>>>>>>>>>> >>>>>>>>>>> What we should do is to create a page for themes and links to it (and >>>>>>>>>>> they should be in catalog) :) >>>>>>>>>>> >>>>>>>>>>> Well, it was me who proposed the slice and yes, I was aware of the >>>>>>>>>>> fact that I should not do it because of code freeze (I was not aware of the >>>>>>>>>>> two themes policy). >>>>>>>>>> >>>>>>>>>> it is not a policy, it is just the idea I have :) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We can remove it again, I will prepare a slice. >>>>>>>>>> >>>>>>>>>> problem with it is that is makes ripples. >>>>>>>>>> If community want it (is nice), we can include it, but I would wait >>>>>>>>>> for P7, yes. >>>>>>>>>> >>>>>>>>>> https://pharo.fogbugz.com/f/cases/19801/Remove-SublimishTheme >>>>>>>>>> At least it was an advertisement for this theme that moved it forward >>>>>>>>>> and the integration of it helped to improve the dark theme too. And showed >>>>>>>>>> again how much we need the concept of palettes used strictly in the system. >>>>>>>>>> >>>>>>>>>> -- Pavel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Esteban >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- Pavel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Esteban >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Phil >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 6, 2017 at 7:43 AM, Esteban Lorenzano >>>>>>>>>>>> <estebanlm(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 6 Mar 2017, at 07:17, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> First, let me be clear: I *like* sublimish theme (not for my use, >>>>>>>>>>>>> but I like it), and I like (a lot) the windows list on spotter, and I like >>>>>>>>>>>>> in general all this new additions. >>>>>>>>>>>> >>>>>>>>>>>> By the way, even if I like it, I would not have integrated >>>>>>>>>>>> SublimishTheme. For same reason I didnât integrated DarkMetalTheme: My idea >>>>>>>>>>>> is to have just two themes *in image*: one white, one dark, and allow people >>>>>>>>>>>> to install other themes from catalog. >>>>>>>>>>>> >>>>>>>>>>>> Why? Because each class inside image becomes our responsibility and >>>>>>>>>>>> then a maintainability issue. With themes in particular already happened >>>>>>>>>>>> that existing themes became abandonware inside the image and we needed to >>>>>>>>>>>> clean up, not without problems. >>>>>>>>>>>> >>>>>>>>>>>> cheers, >>>>>>>>>>>> Esteban >>>>>>>>>>>> >>>>>>>>>>>> ps: which means also yes: that issue got integrated because I failed >>>>>>>>>>>> to control the flow of issues... >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> And I know, most of those additions are usability enhancements so a >>>>>>>>>>>>> good thing. >>>>>>>>>>>>> >>>>>>>>>>>>> But can you guys stop pushing new features into a (in theory) >>>>>>>>>>>>> frozen version? >>>>>>>>>>>>> >>>>>>>>>>>>> Pharo 7 will arrive soonâ¦ *if* we can fix all things missing. If I >>>>>>>>>>>>> can suggest an orientation, it would be good, for those that use linux and >>>>>>>>>>>>> mac (windows is not ready), to test and help fix 64bits version. >>>>>>>>>>>>> >>>>>>>>>>>>> There are still plenty of bugs to fix there, like for example why >>>>>>>>>>>>> Spotter does not shows search line. >>>>>>>>>>>>> >>>>>>>>>>>>> Last week I added support to Athens and SDL2 in 64bits but that >>>>>>>>>>>>> meant: >>>>>>>>>>>>> >>>>>>>>>>>>> - some important changes in UFFI >>>>>>>>>>>>> - discover something that seems is failing on callbacks for Cairo >>>>>>>>>>>>> (no idea if it is a callbacks problem or an image problem that causes a >>>>>>>>>>>>> callback problem). >>>>>>>>>>>>> >>>>>>>>>>>>> I would say all this and the fact we are working on 64bits in >>>>>>>>>>>>> general deserves a lot of testing. >>>>>>>>>>>>> >>>>>>>>>>>>> I will add links in Pharo page to download 64bits (Iâm at the train >>>>>>>>>>>>> now), but in the mean time you can download all from here: >>>>>>>>>>>>> >>>>>>>>>>>>> http://files.pharo.org/get-files/60/pharo-64.zip >>>>>>>>>>>>> http://files.pharo.org/get-files/60/pharo64-linux-latest.zip >>>>>>>>>>>>> (linux) >>>>>>>>>>>>> http://files.pharo.org/get-files/60/pharo64-mac-latest.zip (mac) >>>>>>>>>>>>> http://files.pharo.org/get-files/60/sources.zip (in case you need >>>>>>>>>>>>> them) >>>>>>>>>>>>> >>>>>>>>>>>>> cheers, >>>>>>>>>>>>> Esteban >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "Every successful trip needs a suitable vehicle."

March 9, 2017

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

by Max Leske

Fixing a race condition in handling open sockets when forking an image. At first I had no clue where the problem could come from, then I spent a lot of time guessing at the conditions (of course, being a race condition there was no means to force the specific condition but I didn't know that yet). Over all I spent about 6 weeks on this bug and finally fixed it by creating a new primitive to handle that specific case. I'm not sure what tools could have helped me as this was a rather specific problem (OSProcess). But the hardest problems in my experience are usually concurrency / asynchrony (e.g. race conditions) or bugs in libraries (where you always assume that you must have made a mistake, never the library). Max > 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. > > Stef

March 9, 2017