- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FogBugz (Case [Issue]10840) Collection - WeakSet>>#size utterly broken

by Igor Stasenko

On 10 June 2013 05:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jun 7, 2013 at 1:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: >> >> Hi eliot >> >> probably a really stupid question. >> But why count the number of finalization would have a link with the size? > > > The size can only change when a) an element is added or removed, or b) when > something is finalized. a) adjusts the tally, b) does not. So invalidating > the size on b) means that it will always be recomputed if finalization > affects the size. > i correcting you b) when something is garbage collected. >> >> Is there an invariant that would mean that there is a one one relations >> between object in the set and their garbage collection. >> I mean if two objects of the same weakset are garbage collected will the >> finalization process runs twice > > > No. Finalization runs once after each GC that finalizes something. i.e. the > GC runs, and if it deletes one or more elements from any of the weak > collections in the system it signals the finalization semaphore. So the > finalization loop runs once for each GC that finalizes at least one weak > collection. If a GC finalizes many weak collections the finalization loop > still runs only once for the GC. Except from the cases, when you put too many things into finalization process, producing much garbage, which causing another GC while running it.. Then it turns into self-supporting process: - running finalization process causing GC - GC causing running finalization process :) >> I did not look at the class comment because may be it explains it and now >> I 'm dead. >> >> Stef > > > > > -- > best, > Eliot -- Best regards, Igor Stasenko.

June 10, 2013

Re: [Pharo-dev] [Moose-dev] SourceCity works

by Igor Stasenko

On 10 June 2013 05:53, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Apparently, you have no idea what you talking about. > > Great communication skills :-) > Yes, i felt offended. Because it exists for 2 years for now. And your just saying to people that it doesn't exists, just because you loaded wrong/outdated config. You could just search mailing list (dated back to 2010 when it was first released), before/instead of doing any conclusions. Because if i would miss this mail: you/your student would be just wasting precious time trying to make something which already exists. Now tell me, who should care more about your time, me or yourself? >> Open browser and look for NBOpenGL-X and NBXLib-Core packages. >> I have put Javier in CC since he would be very interesting in >> discovering that things he did does not exist :) > > When I evaluate "NBGLContextDriver allSubclasses" it returns: > an OrderedCollection(NBMacGLContextDriver NBWin32GLContextDriver) > > Nothing wrong in thinking that there is no binding for Linux. Look, Alex... by analogy, i can download Squeak 3.9 image and state that Pharo doesn't exists on pharo mailing list... and nothing wrong in thinking that. What version you are using? NBGLContextDriver allSubclasses an OrderedCollection(NBMacGLContextDriver NBWin32GLContextDriver NBGLXContextDriver) > > When I was trying to make open gl working, I have seen ConfigurationOfNBXLib and the NBXLib* packages. http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL does not say a word what these packages are for. I can imagine NBOpenGL is to interact with OpenGL. Maybe "NB" stands for NativeBoost. But NBXLib no idea. Oh well... Maybe for the X-Server? But is this related to OpenGL? > Yes it is related. Linux desktop uses X server, to initialize OpenGL context there you must create an X window first. For all 'maybes' , google has an answer: try googling 'opengl linux' click on 1st hit , and read linux section: " Linux Graphics on Linux is almost exclusively implemented using the X windows system. Supporting OpenGL on Linux involves using GLX extensions to the X Server. " > Today I succeeded to make OpenGL running on my machine. Cool stuff! Thanks for this! > Now imagine, that the problems you had to deal with, is a norm in C world for anything: missing dependencies, found it, but it doesn't compiles, compiled but it doesn't works, works but sometimes crashes etc etc. > Cheers, > Alexandre > -- Best regards, Igor Stasenko.

June 10, 2013

Re: [Pharo-dev] Tabs

by Benjamin

I am not convinced by this one :) Anyway, it's a theme concern :) (or should be ^^) Ben On Jun 10, 2013, at 11:18 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Cool stuff! > > Another funny task: multicolor tabs like colorfullTabs mozilla plugin > > 2013/6/10 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > Holidays are for doing fun stuff :) > > And it was fun :) > (and actually pretty easy except the very last steps :P) > > Ben > > On Jun 9, 2013, at 11:49 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Benjamin Van Ryseghem-2 wrote >>> I would like to introduce a new implementation of tabs with the following >>> features (for now): >> >> Wow, amazing work. This better not be what you were doing on vacation!! >> Holidays are for rest ;) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Pharo-dev-Tabs-tp4692498p4692521.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

June 10, 2013

Re: [Pharo-dev] Tabs

by Benjamin

Thank you :) A preview could be something fun indeed :) Ben On Jun 10, 2013, at 11:14 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > Really Great works Benjamin . The multi select feature with the split is a > brilliant idea. Hovering above tabs gives also a preview of them like what > happens with pharo windows when they are minimised ? > > I think Opera has such feartue for tabs. > > > > -- > View this message in context: http://forum.world.st/Pharo-dev-Tabs-tp4692498p4692593.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 10, 2013

[update 3.0] #30190

by StÃ©phane Ducasse

30190 ----- 10779 - Parsing faulty method ends with incorrect ast. Thanks Gisela https://pharo.fogbugz.com/default.asp? 10801 - Use UTF8 encoding in MC snapshot source.st https://pharo.fogbugz.com/default.asp?10801 Thanks nicolas cellier and sven. Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Installers-StephaneDuc… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-StephaneDucasse.81… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compression-StephaneDucasse.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Tests-Core-StephaneDucass… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-StephaneDucasse.166.…

June 10, 2013

Re: [Pharo-dev] Tabs

by Denis Kudriashov

Cool stuff! Another funny task: multicolor tabs like colorfullTabs mozilla plugin 2013/6/10 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > Holidays are for doing fun stuff :) > > And it was fun :) > (and actually pretty easy except the very last steps :P) > > Ben > > On Jun 9, 2013, at 11:49 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> > wrote: > > Benjamin Van Ryseghem-2 wrote > > I would like to introduce a new implementation of tabs with the following > features (for now): > > > Wow, amazing work. This better not be what you were doing on vacation!! > Holidays are for rest ;) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-dev-Tabs-tp4692498p4692521.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

June 10, 2013

Re: [Pharo-dev] Tabs

by kilon

Really Great works Benjamin . The multi select feature with the split is a brilliant idea. Hovering above tabs gives also a preview of them like what happens with pharo windows when they are minimised ? I think Opera has such feartue for tabs. -- View this message in context: http://forum.world.st/Pharo-dev-Tabs-tp4692498p4692593.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 10, 2013

Re: [Pharo-dev] Necessity of TDD with Smalltalk

by Dennis Schetinin

I have no vimeo account needed to comment, so I'll answer here. At 9:38 you are starting to move the parsing logic from StringCalculator to a (non-existent yet) Tokenizer. That's what mock objects are used for: simulate an object that is needed for a test but was not constructed yet. Thus, I would start with a test like the following: StringCalculatorTests >> testUsesTokenizer | calculator | calculator := StringCalculator new. [ :tokenizer | calculator tokenizer: tokenizer. [result := calculator add: '//;\n1;2'] should strictly satisfy: [tokenizer findTokens willReturn: #(1 2)]. result should be: 3. ] runScenario Then, I'd go exactly the same way: replacing the parsing logic with tokenizer call would make the new test green but break the testAddCustomDelimiter. Then I'll create the Tokenizer class, paste the logic there and make all the tests green. With this I'd still miss a unit test for Tokenizer, but I don't think it's a big issue as I don't have to design its logic here. The testUsesTokenizer seems to duplicate the testAddCustomDelimiter, but actually is does not as it used for a different purpose and just shares a test case (I actually can use any other figures here just to be sure calculator properly uses the output of tokenizer). -- Best regards, Dennis Schetinin 2013/6/7 Rafael Luque <rafael.luque.leiva(a)gmail.com> > Dennis, It would be great to receive your ideas about how to use mocks in > this case. Feel free to add any comment directly in the screencast at Vimeo > (http://vimeo.com/19591202) > > Thank you! > > > 2013/6/7 Dennis Schetinin <chaetal(a)gmail.com> > >> As for me, the StringCalculator kata is a very good (or better to say >> nearly perfect) demo of a classic TDD approach: small and fast steps, live >> objectsâ¦ really nice! >> >> Though I see (feel?) some issuesâ¦ mostly about factoring-out new classes >> without tests (yes, that was refactoringâ¦ but still), I believe, that's >> beyond classic approach and only top-down TDD with mocks may help to keep >> TDD pure here. (I've scheduled a task for detailed exploration of how mocks >> can be used here to provide "seamless" TDD in this case.) >> >> So, this screencast is a great lesson on TDD in Smalltalk. >> >> >> >> -- >> >> Best regards, >> >> >> Dennis Schetinin >> >> >> 2013/6/7 Rafael Luque <rafael.luque.leiva(a)gmail.com> >> >>> Hi Dennis, >>> >>> What do you think about the approach shown in this screencast: >>> http://www.pharocasts.com/2011/02/stringcalculator-kata.html ? >>> >>> I'm far away from being an Smalltalk developer, but I tried to show a >>> TDD process to solve this simple kata. >>> >>> Rafael Luque >>> >>> >>> 2013/6/7 Dennis Schetinin <chaetal(a)gmail.com> >>> >>>> I don't remember exactly where and when, but I think we've discussed >>>> the Laser Game tutorial already. I told this before, and I (after reviewing >>>> the tutorial again) should repeat it again: actually, this tutorial doesn't >>>> show TDD. I can explain my opinion in detail if someone's interested, but >>>> in general, that's simply an up-front design approach with some automatic >>>> testing. It's not even "Test-First" approach most of time. >>>> >>>> Disclaimer: I don't mean the tutorial and/or the design approach used >>>> there are bad. I like this tutorial. It's really very good: it shows many >>>> aspects for Smalltalk programing, it shows how to use debugger and >>>> inspectors properly. I borrowed many ideas from there for my Smalltalk >>>> programming courseâ¦ It's just not TDD, not "pure" TDD at least. >>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> >>>> >>>> Dennis Schetinin >>>> >>>> >>>> 2013/6/7 <btc(a)openinworld.com> >>>> >>>> Paul Davidowitz wrote: >>>>> >>>>>> It seems to me that a big reason for developing via writing tests >>>>>> first >>>>>> (Test Driven Development) is that the tests serve as a debugging tool >>>>>> -- >>>>>> if a test breaks, then the last piece of (non-test) code that change >>>>>> is >>>>>> likely the culprit. But with the powerful debugging environment that >>>>>> comes with Smalltalk, I am wondering of the utility of TDD (TDD is big >>>>>> in the Ruby camp perhaps for a reason). After all, writing and >>>>>> re-writing the tests becomes quite a non-trivial chore (not to mention >>>>>> that the tests themselves could be buggy). So my question: Is it ok >>>>>> in >>>>>> Smalltalk to write tests afterwards? Is it even perhaps recommended? >>>>>> >>>>>> - Paul >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Actually some Smalltalk'ers consider the debugger a major facilitator >>>>> of TDD by mostly coding from within the debugger. >>>>> 1. Before writing any application code, write a test. >>>>> 2. Execute that test straight away. Of course it fails because you >>>>> haven't written any application code. >>>>> 3. Up comes the debugger - now "from within the debugger" add the >>>>> application code needed to satisfy the test. >>>>> 4. Repeat. >>>>> >>>>> A good demonstration of this is Stephan Wessels' Laser Game tutorial >>>>> [1] (but you'll temporarily need to revert to Squeak 3.9 to do it) >>>>> cheers -ben >>>>> >>>>> >>>>> >>>> >>> >> >

June 10, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 2 regressions found. Tests.Monticello.MCMczInstallerTest.testInstallFromFile Tests.Monticello.MCMczInstallerTest.testInstallFromStream

June 10, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 2 regressions found. Tests.Monticello.MCMczInstallerTest.testInstallFromFile Tests.Monticello.MCMczInstallerTest.testInstallFromStream

June 10, 2013