August 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] where is hosted Grease?

by StÃ©phane Ducasse

Soon smalltalkhub project will have inbox. Right now this is annoying :) Nicolas is aware of that. >>> I did a separate repository, let me know if you want to be added as contributor >>> >>> http://smalltalkhub.com/#!/~hernan/Grease >> >> We should not "hijack" such projects into "private" STHub users like Hernan's private URL. >> SmalltalkHub already has team functionality and the according teams are already setup. > > Ok, but please keep the code updated because I have to fix Grease to work in Pharo 2.0 I can understand. We wanted for long time a Grease version that does not dirty our moose packages. >> Grease belongs to Seaside since it was developed by the seaside team. Therefore >> it should be a "Seaside team" project also on STHub as before. >> >> There are already team projects for the Seaside team. See http://smalltalkhub.com/#!/~Seaside >> with already migrated code. >> >> So for Grease we/or the seaside team should use: >> >> http://smalltalkhub.com/#!/~Seaside/Grease >> >> We should align with the seaside team/developers, otherwise we would add more confusion >> regarding the code move and the configuration. >> > > That is like saying everyone have to be in the Seaside team to upload just a fix in Grease? > > Cheers, > > HernÃ¡n > >> Thanks >> T. >> >> > >

Aug. 31, 2013

Where is hosted Grease?

by Torsten Bergmann

Looks like http://smalltalkhub.com/#!/~Seaside/Seaside31/ and http://smalltalkhub.com/#!/~Seaside/Seaside30 already contain Grease. So it is already migrated to STHub. In it's current state it's directly bound to Seaside. There is now also a Jenkins Job [1] and it looks like version 1.0.8/baseline 1.0.8 of ConfigurationOfGrease refer to http://www.smalltalkhub.com/mc/Seaside/Seaside30/main So I dont know if http://smalltalkhub.com/#!/~Seaside/Grease or http://smalltalkhub.com/#!/~hernan/Grease are really necessary. I've limited net access these days - maybe someone can clearify about a future Grease repo on the "seaside-dev" mailinglist. Since the Seaside community invented/implemented Grease I agree with Tobias that it is (by default) the official maintainer and should decide to avoid many forks/teams. Thx T. [1] http://lists.squeakfoundation.org/pipermail/seaside-dev/2013-August/005341.…

Aug. 31, 2013

Re: [Pharo-dev] [3.0] Down to 5 failing tests!

by Camillo Bruni

cool! I am on to it for the NativeBoost Manifest. On 2013-08-31, at 17:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Nearly green! > > -> Mac is green > > -> Linux: 2 failing tests > > > NBFFIExternalStructTests > testReturnStruct1Byte > NBFFIExternalUnionTests > testReturnUnion1Byte > > -> Windows: 3 failing tests > > ZnServerTests > testEntityTooLarge > testHeaderLineTooLong > testRequestLineTooLong > > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/ >

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by HernÃ¡n Morales Durand

El 31/08/2013 12:45, Tobias Pape escribiÃ³: > Am 31.08.2013 um 17:00 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > >> El 31/08/2013 11:29, Torsten Bergmann escribiÃ³: >>>> I did a separate repository, let me know if you want to be added as contributor >>>> >>>> http://smalltalkhub.com/#!/~hernan/Grease >>> >>> We should not "hijack" such projects into "private" STHub users like Hernan's private URL. >>> SmalltalkHub already has team functionality and the according teams are already setup. >>> >> >> Ok, but please keep the code updated because I have to fix Grease to work in Pharo 2.0 >> >>> Grease belongs to Seaside since it was developed by the seaside team. Therefore >>> it should be a "Seaside team" project also on STHub as before. >>> >>> There are already team projects for the Seaside team. See http://smalltalkhub.com/#!/~Seaside >>> with already migrated code. >>> >>> So for Grease we/or the seaside team should use: >>> >>> http://smalltalkhub.com/#!/~Seaside/Grease >>> >>> We should align with the seaside team/developers, otherwise we would add more confusion >>> regarding the code move and the configuration. >>> >> >> That is like saying everyone have to be in the Seaside team to upload just a fix in Grease? > > > Then make a grease team. > Grease was invented for Seaside by the seaside team, doesn't > that make the Seaside team the official maintainer? > Then yes, everyone who wants his fix in the official Grease > repo has to be on that team or ask someone there to merge/integrate/upload. > Ok, if someone make a Grease team I will be happy to be part of :) Cheers, HernÃ¡n

Aug. 31, 2013

[3.0] Down to 5 failing tests!

by Marcus Denker

Nearly green! -> Mac is green -> Linux: 2 failing tests NBFFIExternalStructTests testReturnStruct1Byte NBFFIExternalUnionTests testReturnUnion1Byte -> Windows: 3 failing tests ZnServerTests testEntityTooLarge testHeaderLineTooLong testRequestLineTooLong https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by Tobias Pape

Am 31.08.2013 um 17:00 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > El 31/08/2013 11:29, Torsten Bergmann escribiÃ³: >>> I did a separate repository, let me know if you want to be added as contributor >>> >>> http://smalltalkhub.com/#!/~hernan/Grease >> >> We should not "hijack" such projects into "private" STHub users like Hernan's private URL. >> SmalltalkHub already has team functionality and the according teams are already setup. >> > > Ok, but please keep the code updated because I have to fix Grease to work in Pharo 2.0 > >> Grease belongs to Seaside since it was developed by the seaside team. Therefore >> it should be a "Seaside team" project also on STHub as before. >> >> There are already team projects for the Seaside team. See http://smalltalkhub.com/#!/~Seaside >> with already migrated code. >> >> So for Grease we/or the seaside team should use: >> >> http://smalltalkhub.com/#!/~Seaside/Grease >> >> We should align with the seaside team/developers, otherwise we would add more confusion >> regarding the code move and the configuration. >> > > That is like saying everyone have to be in the Seaside team to upload just a fix in Grease? Then make a grease team. Grease was invented for Seaside by the seaside team, doesn't that make the Seaside team the official maintainer? Then yes, everyone who wants his fix in the official Grease repo has to be on that team or ask someone there to merge/integrate/upload. Best -Tobias

Aug. 31, 2013

[update 3.0] #30362

by Marcus Denker

30362 ----- 11510 Endless loop trying to get a menu on AbstractNautilusUI https://pharo.fogbugz.com/f/cases/11510 11518 Failing test: .testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits https://pharo.fogbugz.com/f/cases/11518 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.528.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-MarcusDenker…

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by HernÃ¡n Morales Durand

El 31/08/2013 11:29, Torsten Bergmann escribiÃ³: >> I did a separate repository, let me know if you want to be added as contributor >> >> http://smalltalkhub.com/#!/~hernan/Grease > > We should not "hijack" such projects into "private" STHub users like Hernan's private URL. > SmalltalkHub already has team functionality and the according teams are already setup. > Ok, but please keep the code updated because I have to fix Grease to work in Pharo 2.0 > Grease belongs to Seaside since it was developed by the seaside team. Therefore > it should be a "Seaside team" project also on STHub as before. > > There are already team projects for the Seaside team. See http://smalltalkhub.com/#!/~Seaside > with already migrated code. > > So for Grease we/or the seaside team should use: > > http://smalltalkhub.com/#!/~Seaside/Grease > > We should align with the seaside team/developers, otherwise we would add more confusion > regarding the code move and the configuration. > That is like saying everyone have to be in the Seaside team to upload just a fix in Grease? Cheers, HernÃ¡n > Thanks > T. > >

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by StÃ©phane Ducasse

On Aug 31, 2013, at 4:29 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> I did a separate repository, let me know if you want to be added as contributor >> >> http://smalltalkhub.com/#!/~hernan/Grease > > We should not "hijack" such projects into "private" STHub users like Hernan's private URL. > SmalltalkHub already has team functionality and the according teams are already setup. > > Grease belongs to Seaside since it was developed by the seaside team. Therefore > it should be a "Seaside team" project also on STHub as before. yes but it does not have to be under Seaside > There are already team projects for the Seaside team. See http://smalltalkhub.com/#!/~Seaside > with already migrated code. > > So for Grease we/or the seaside team should use: > > http://smalltalkhub.com/#!/~Seaside/Grease Good that you created it :) > > We should align with the seaside team/developers, otherwise we would add more confusion > regarding the code move and the configuration. Indeed > > Thanks > T. >

Aug. 31, 2013

where is hosted Grease?

by Torsten Bergmann

> I did a separate repository, let me know if you want to be added as contributor > > http://smalltalkhub.com/#!/~hernan/Grease We should not "hijack" such projects into "private" STHub users like Hernan's private URL. SmalltalkHub already has team functionality and the according teams are already setup. Grease belongs to Seaside since it was developed by the seaside team. Therefore it should be a "Seaside team" project also on STHub as before. There are already team projects for the Seaside team. See http://smalltalkhub.com/#!/~Seaside with already migrated code. So for Grease we/or the seaside team should use: http://smalltalkhub.com/#!/~Seaside/Grease We should align with the seaside team/developers, otherwise we would add more confusion regarding the code move and the configuration. Thanks T.

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by StÃ©phane Ducasse

Oki Stef > Mind that Seaside/Seaside31 has a newer version of Grease embedded. > > The idea was already raised and +- agreed that it should go in a separate repo but then you should get the newer version. > > Seaside30 will have to continue with its old version but Seaside3.1 should then keep up with the one in the separate repo. > > > Johan (sent from my mobile) > > On 31 Aug 2013, at 15:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I saw :) >> I will ask damien because he was fixing the configurations recently and we could do a concerted effort. >> >> Stef >> >> On Aug 31, 2013, at 3:01 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >>> I did a separate repository, let me know if you want to be added as contributor >>> >>> http://smalltalkhub.com/#!/~hernan/Grease >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> El 31/08/2013 9:31, StÃ©phane Ducasse escribiÃ³: >>>> apparently it is in Seaside/Seaside30 >>>> >>>> and it would be good to have Grease may be in as a separate "package" ie Seaside/Grease or Grease >>>> >>>> Stef >>>> >>>> >>>>> because PostMark depends on it and I would like to get the latest version >>>>> >>>>> Stef >> >> >

Aug. 31, 2013

Thanks for the configuration Browser :)

by Torsten Bergmann

You're welcome! Having easy access is key for people to use stuff. So I can just remind anyone to put their working configs for Pharo 2.0 into http://ss3.gemtalksystems.com/ss/MetaRepoForPharo20.html Pharo 3.0 into http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main This will allow people to find and load your code easily. Thx T.

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by Johan Brichau

Mind that Seaside/Seaside31 has a newer version of Grease embedded. The idea was already raised and +- agreed that it should go in a separate repo but then you should get the newer version. Seaside30 will have to continue with its old version but Seaside3.1 should then keep up with the one in the separate repo. Johan (sent from my mobile) On 31 Aug 2013, at 15:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I saw :) > I will ask damien because he was fixing the configurations recently and we could do a concerted effort. > > Stef > > On Aug 31, 2013, at 3:01 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > >> I did a separate repository, let me know if you want to be added as contributor >> >> http://smalltalkhub.com/#!/~hernan/Grease >> >> Cheers, >> >> HernÃ¡n >> >> El 31/08/2013 9:31, StÃ©phane Ducasse escribiÃ³: >>> apparently it is in Seaside/Seaside30 >>> >>> and it would be good to have Grease may be in as a separate "package" ie Seaside/Grease or Grease >>> >>> Stef >>> >>> >>>> because PostMark depends on it and I would like to get the latest version >>>> >>>> Stef > >

Aug. 31, 2013

JSON project migrated to the SmalltalkHub + configuration

by StÃ©phane Ducasse

Hi guys I migrated the JSON squeaksource project and defined a configuration for it. I added catalog description. If the original user want to maintain it. I would delighted, else we will have a look at it. I needed it for a nice configuration of Postmark. Stef

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by StÃ©phane Ducasse

I saw :) I will ask damien because he was fixing the configurations recently and we could do a concerted effort. Stef On Aug 31, 2013, at 3:01 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > I did a separate repository, let me know if you want to be added as contributor > > http://smalltalkhub.com/#!/~hernan/Grease > > Cheers, > > HernÃ¡n > > El 31/08/2013 9:31, StÃ©phane Ducasse escribiÃ³: >> apparently it is in Seaside/Seaside30 >> >> and it would be good to have Grease may be in as a separate "package" ie Seaside/Grease or Grease >> >> Stef >> >> >>> because PostMark depends on it and I would like to get the latest version >>> >>> Stef >>> >> >> >> > >

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by HernÃ¡n Morales Durand

I did a separate repository, let me know if you want to be added as contributor http://smalltalkhub.com/#!/~hernan/Grease Cheers, HernÃ¡n El 31/08/2013 9:31, StÃ©phane Ducasse escribiÃ³: > apparently it is in Seaside/Seaside30 > > and it would be good to have Grease may be in as a separate "package" ie Seaside/Grease or Grease > > Stef > > >> because PostMark depends on it and I would like to get the latest version >> >> Stef >> > > >

Aug. 31, 2013

Re: [Pharo-dev] where is hosted Grease?

by StÃ©phane Ducasse

apparently it is in Seaside/Seaside30 and it would be good to have Grease may be in as a separate "package" ie Seaside/Grease or Grease Stef > because PostMark depends on it and I would like to get the latest version > > Stef >

Aug. 31, 2013

where is hosted Grease?

by StÃ©phane Ducasse

because PostMark depends on it and I would like to get the latest version Stef

Aug. 31, 2013

About MetacelloRepository

by StÃ©phane Ducasse

Hi guys I suggest to move it to PharoExtras on SmalltalkHub. What do you think? I can do it of course :) Stef

Aug. 31, 2013

Units has now a configuration and a catalog description

by StÃ©phane Ducasse

Hi guys I published a configuration for Units in the Units on Smalltalk/MarcusDenker. Now we should be able to express nice project dependencies. Stef

Aug. 31, 2013

[update 3.0] #30361

by Marcus Denker

30361 ----- 11512 CI: Release tests are being run multiple times https://pharo.fogbugz.com/f/cases/11512 11500 Wrong use of #defer: causes growing stack in CommandLineHandler https://pharo.fogbugz.com/f/cases/11500 11499 CMD-Click is very slow in Nautilus https://pharo.fogbugz.com/f/cases/11499/ Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/UIManager-MarcusDenker.112.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk…

Aug. 31, 2013

Thanks for the configuration Browser :)

by StÃ©phane Ducasse

and for the configurations that are up to dateâ¦ In 3 min I could load Smacc in Pharo2.0 Stef

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by StÃ©phane Ducasse

> > > i didn't said i don't believe it. > But what someone said (it was Esteban or someone else) in conversation, > that existence of documentation does not guarantees there will be no abuses. > Because , at the end, the developer can simply disagree with author's POV, > and so he intentionally picks "not recommended" way. > Of course it is not an excuse for not writing a documentation :) :) Igor if you write some notex in telegraphic styles I can spend time fleshing them . > > stef > > On Aug 30, 2013, at 1:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> the more i looking how people using announcements, the more it reminds me the quote: >> if the only tool you have is a hammer, to treat everything as if it were a nail >> >> >> On 30 August 2013 13:38, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> On 30 August 2013 13:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: >> >> > can someone explain me, PLEASE, what is it for, >> > and why there are announcer per each subclass of TestCase needed >> > and why you organize it in a dictionary >> >> It should be a class side instance variable instead of a classVar that maps test cases to announcer. >> >> why? >> >> Anyway the whole announcement stuff in SUnit is weird. >> There TestAnnouncement (used by TestRunner) and an independent TestCaseAnnouncement hierarchy (that nobody use). >> And there is this TestAnnouncer that subclass SystemAnnouncer... >> >> that i already dealt with. >> >> But really.. why whole SUnit package needs more than one announcer announcing all events happening about running tests, >> why people so obsessive with announcers that they put them everywhere?? >> >> >> > ... and.. do we need so many announcers >> > everywhere? >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > > -- > Best regards, > Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Aida 6.6 Web Framework Released

by StÃ©phane Ducasse

>> >> >> New version of Aida/Web framework and application server >> (http://www.aidaweb.si) is here with: >> >> - optimization on HTTP level to send first byte to the client as soon >> as possible >> - streaming of HTML, specially header to get first byte out >> immediately, >> - gzip compression of all text stuff like CSS, JS etc >> - CSS Sprites support added >> - internal vs. extarnal IP detection, to control access rights >> accordingly >> - Geolocation support improved >> - all JS and CSS libraries updated to latest versions, Twitter >> Bootstrap v3 added in parallel to v2.x > > Great work, thanks, Janko. + 1 Janko if you need scripts to migrate to SmalltalkHub let me know.

Aug. 30, 2013

Re: [Pharo-dev] Debugger recursion

by jan.struz

added issue 11517: https://pharo.fogbugz.com/f/cases/11517/Installed-Breakpoint-can-cause-recu… Igor Stasenko wrote > that means that breakpoint should trigger only once > and then immediately place a recursion guard, so next time it enters the > breakpoint, it checks against recursion and passing by. > > > On 30 August 2013 17:42, Marcus Denker < > marcus.denker@ > > wrote: > >> >> On Aug 30, 2013, at 5:13 PM, jan.struz < > public+pharo@ > > wrote: >> >> > one more endless loop, on Pharo3 & Pharo2, evaluate this code: >> > >> > BreakpointManager installInClass: FileSystem selector: >> #stringFromPath:. >> > 'C:\' asFileReference fullName. >> > >> > no debugger, cannot interrupt, freezed image(especially 2.0) >> > this one is going to end in bugtracker, I think... :) >> > >> > >> Yes, opening the debugger opens a file. So the breakpoint calls the >> method >> againâ¦ >> >> Oh, Meta-recursion :-) >> >> http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf >> >> Marcus >> >> >> > >> > Mariano Martinez Peck wrote >> >> On Wed, Aug 28, 2013 at 11:18 AM, jan.struz < >> > >> >> public+pharo@ >> > >> >> > wrote: >> >> >> >>> Hi all, >> >>> I have a solution for the recursion in Pharo 2.0. (For those >> subclassing >> >>> ProtoObject, of course :-) ) >> >>> If the subclass of ProtoObject implements #class, then the Debugger >> is >> >>> happy >> >>> (will open a debugger). >> >>> #class is the first message sent by Debugger, to continue with full >> >>> debugger >> >>> & deeper inspecting the instance, one have to implement the rest - >> >>> #isMemberOf: #isKindOf: #inspectorClass #printStringLimitedTo: >> >>> #longPrintOn:limitedTo:indent: #defaultLabelForInspector >> >>> #longPrintStringLimitedTo: (minimal set) >> >>> All of these messages pops up in debugger as MNU, and I am able to >> debug >> >>> it. >> >>> (I hope this will be useful for someone...) >> >>> >> >>> In the latest Pharo 3.0 (30351), implementing the first message (here >> it >> >>> is >> >>> #printStringLimitedTo:) is not enough, I have to implement another >> >>> methods >> >>> (ex. #inspector) and in addition #basicSize and #-> (in short, all of >> >>> them, >> >>> needed by debugger). >> >>> Without that, I am not able to debug it. The good thing in Pharo3 is, >> >>> that >> >>> the image is responding, and I can see what is happening in >> >>> ProcessBrowser >> >>> and so, without interrupting. >> >>> >> >>> Mariano, the Ghost proxies are really great, only I think the logging >> >>> should >> >>> be optional and turned off by default. So it could be referenced by >> >>> another >> >>> project and ready to use. >> >>> >> >> >> >> Indeed. I thought it was disabled by default. >> >> >> >> >> >>> It's interesting to see the (no)difference between the >> debuggingMessages >> >>> in >> >>> Ghost, and these needed for ProtoObject subclass... :-) >> >>> >> >>> >> >> It seems you were not the first fighting with that :) >> >> Maybe it's time to document all this by having integrated in the image >> a >> >> DebuggeableProtoObject? Subclass of ProtoObject and implementing the >> >> needed >> >> methods? >> >> Those that could be implemented, can be implemented and those that >> would >> >> depend on the usage, could be implemented as "self >> >> subclassResponsability". >> >> But what is important is that such a class will document the needed >> >> methods >> >> in order to proper debug/inspect subclasses of ProtoObject. >> > >> > I like the idea, but it doesn't depend on me... >> > >> > >> >> Cheers, >> >> >> >> >> >> >> >>> Igor, you are right, the possibility to break something is not a bug, >> >>> indeed >> >>> :-) I know. >> >>> >> >>> >> >>> >> >>> >> >>> ----- >> >>> Save The World! >> >>> -- >> >>> View this message in context: >> >>> http://forum.world.st/Debugger-recursion-tp4704703p4705487.html >> >>> Sent from the Pharo Smalltalk Developers mailing list archive at >> >>> Nabble.com. >> >>> >> >>> >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> > >> > >> > >> > >> > >> > ----- >> > Save The World! >> > -- >> > View this message in context: >> http://forum.world.st/Debugger-recursion-tp4704703p4705815.html >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> > >> >> > > > -- > Best regards, > Igor Stasenko. ----- Save The World! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705841.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 30, 2013

Re: [Pharo-dev] Debugger recursion

by Igor Stasenko

that means that breakpoint should trigger only once and then immediately place a recursion guard, so next time it enters the breakpoint, it checks against recursion and passing by. On 30 August 2013 17:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 30, 2013, at 5:13 PM, jan.struz <public+pharo(a)struz.cz> wrote: > > > one more endless loop, on Pharo3 & Pharo2, evaluate this code: > > > > BreakpointManager installInClass: FileSystem selector: #stringFromPath:. > > 'C:\' asFileReference fullName. > > > > no debugger, cannot interrupt, freezed image(especially 2.0) > > this one is going to end in bugtracker, I think... :) > > > > > Yes, opening the debugger opens a file. So the breakpoint calls the method > againâ¦ > > Oh, Meta-recursion :-) > > http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf > > Marcus > > > > > > Mariano Martinez Peck wrote > >> On Wed, Aug 28, 2013 at 11:18 AM, jan.struz < > > > >> public+pharo@ > > > >> > wrote: > >> > >>> Hi all, > >>> I have a solution for the recursion in Pharo 2.0. (For those > subclassing > >>> ProtoObject, of course :-) ) > >>> If the subclass of ProtoObject implements #class, then the Debugger is > >>> happy > >>> (will open a debugger). > >>> #class is the first message sent by Debugger, to continue with full > >>> debugger > >>> & deeper inspecting the instance, one have to implement the rest - > >>> #isMemberOf: #isKindOf: #inspectorClass #printStringLimitedTo: > >>> #longPrintOn:limitedTo:indent: #defaultLabelForInspector > >>> #longPrintStringLimitedTo: (minimal set) > >>> All of these messages pops up in debugger as MNU, and I am able to > debug > >>> it. > >>> (I hope this will be useful for someone...) > >>> > >>> In the latest Pharo 3.0 (30351), implementing the first message (here > it > >>> is > >>> #printStringLimitedTo:) is not enough, I have to implement another > >>> methods > >>> (ex. #inspector) and in addition #basicSize and #-> (in short, all of > >>> them, > >>> needed by debugger). > >>> Without that, I am not able to debug it. The good thing in Pharo3 is, > >>> that > >>> the image is responding, and I can see what is happening in > >>> ProcessBrowser > >>> and so, without interrupting. > >>> > >>> Mariano, the Ghost proxies are really great, only I think the logging > >>> should > >>> be optional and turned off by default. So it could be referenced by > >>> another > >>> project and ready to use. > >>> > >> > >> Indeed. I thought it was disabled by default. > >> > >> > >>> It's interesting to see the (no)difference between the > debuggingMessages > >>> in > >>> Ghost, and these needed for ProtoObject subclass... :-) > >>> > >>> > >> It seems you were not the first fighting with that :) > >> Maybe it's time to document all this by having integrated in the image a > >> DebuggeableProtoObject? Subclass of ProtoObject and implementing the > >> needed > >> methods? > >> Those that could be implemented, can be implemented and those that would > >> depend on the usage, could be implemented as "self > >> subclassResponsability". > >> But what is important is that such a class will document the needed > >> methods > >> in order to proper debug/inspect subclasses of ProtoObject. > > > > I like the idea, but it doesn't depend on me... > > > > > >> Cheers, > >> > >> > >> > >>> Igor, you are right, the possibility to break something is not a bug, > >>> indeed > >>> :-) I know. > >>> > >>> > >>> > >>> > >>> ----- > >>> Save The World! > >>> -- > >>> View this message in context: > >>> http://forum.world.st/Debugger-recursion-tp4704703p4705487.html > >>> Sent from the Pharo Smalltalk Developers mailing list archive at > >>> Nabble.com. > >>> > >>> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > > > > > > > > > > > > ----- > > Save The World! > > -- > > View this message in context: > http://forum.world.st/Debugger-recursion-tp4704703p4705815.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > -- Best regards, Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by btc＠openinworld.com

Aug. 30, 2013

Re: [Pharo-dev] Debugger recursion

by Marcus Denker

On Aug 30, 2013, at 5:13 PM, jan.struz <public+pharo(a)struz.cz> wrote: > one more endless loop, on Pharo3 & Pharo2, evaluate this code: > > BreakpointManager installInClass: FileSystem selector: #stringFromPath:. > 'C:\' asFileReference fullName. > > no debugger, cannot interrupt, freezed image(especially 2.0) > this one is going to end in bugtracker, I think... :) > > Yes, opening the debugger opens a file. So the breakpoint calls the method againâ¦ Oh, Meta-recursion :-) http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf Marcus > > Mariano Martinez Peck wrote >> On Wed, Aug 28, 2013 at 11:18 AM, jan.struz < > >> public+pharo@ > >> > wrote: >> >>> Hi all, >>> I have a solution for the recursion in Pharo 2.0. (For those subclassing >>> ProtoObject, of course :-) ) >>> If the subclass of ProtoObject implements #class, then the Debugger is >>> happy >>> (will open a debugger). >>> #class is the first message sent by Debugger, to continue with full >>> debugger >>> & deeper inspecting the instance, one have to implement the rest - >>> #isMemberOf: #isKindOf: #inspectorClass #printStringLimitedTo: >>> #longPrintOn:limitedTo:indent: #defaultLabelForInspector >>> #longPrintStringLimitedTo: (minimal set) >>> All of these messages pops up in debugger as MNU, and I am able to debug >>> it. >>> (I hope this will be useful for someone...) >>> >>> In the latest Pharo 3.0 (30351), implementing the first message (here it >>> is >>> #printStringLimitedTo:) is not enough, I have to implement another >>> methods >>> (ex. #inspector) and in addition #basicSize and #-> (in short, all of >>> them, >>> needed by debugger). >>> Without that, I am not able to debug it. The good thing in Pharo3 is, >>> that >>> the image is responding, and I can see what is happening in >>> ProcessBrowser >>> and so, without interrupting. >>> >>> Mariano, the Ghost proxies are really great, only I think the logging >>> should >>> be optional and turned off by default. So it could be referenced by >>> another >>> project and ready to use. >>> >> >> Indeed. I thought it was disabled by default. >> >> >>> It's interesting to see the (no)difference between the debuggingMessages >>> in >>> Ghost, and these needed for ProtoObject subclass... :-) >>> >>> >> It seems you were not the first fighting with that :) >> Maybe it's time to document all this by having integrated in the image a >> DebuggeableProtoObject? Subclass of ProtoObject and implementing the >> needed >> methods? >> Those that could be implemented, can be implemented and those that would >> depend on the usage, could be implemented as "self >> subclassResponsability". >> But what is important is that such a class will document the needed >> methods >> in order to proper debug/inspect subclasses of ProtoObject. > > I like the idea, but it doesn't depend on me... > > >> Cheers, >> >> >> >>> Igor, you are right, the possibility to break something is not a bug, >>> indeed >>> :-) I know. >>> >>> >>> >>> >>> ----- >>> Save The World! >>> -- >>> View this message in context: >>> http://forum.world.st/Debugger-recursion-tp4704703p4705487.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > > ----- > Save The World! > -- > View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705815.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 30, 2013

Re: [Pharo-dev] Debugger recursion

by jan.struz

one more endless loop, on Pharo3 & Pharo2, evaluate this code: BreakpointManager installInClass: FileSystem selector: #stringFromPath:. 'C:\' asFileReference fullName. no debugger, cannot interrupt, freezed image(especially 2.0) this one is going to end in bugtracker, I think... :) Mariano Martinez Peck wrote > On Wed, Aug 28, 2013 at 11:18 AM, jan.struz < > public+pharo@ > > wrote: > >> Hi all, >> I have a solution for the recursion in Pharo 2.0. (For those subclassing >> ProtoObject, of course :-) ) >> If the subclass of ProtoObject implements #class, then the Debugger is >> happy >> (will open a debugger). >> #class is the first message sent by Debugger, to continue with full >> debugger >> & deeper inspecting the instance, one have to implement the rest - >> #isMemberOf: #isKindOf: #inspectorClass #printStringLimitedTo: >> #longPrintOn:limitedTo:indent: #defaultLabelForInspector >> #longPrintStringLimitedTo: (minimal set) >> All of these messages pops up in debugger as MNU, and I am able to debug >> it. >> (I hope this will be useful for someone...) >> >> In the latest Pharo 3.0 (30351), implementing the first message (here it >> is >> #printStringLimitedTo:) is not enough, I have to implement another >> methods >> (ex. #inspector) and in addition #basicSize and #-> (in short, all of >> them, >> needed by debugger). >> Without that, I am not able to debug it. The good thing in Pharo3 is, >> that >> the image is responding, and I can see what is happening in >> ProcessBrowser >> and so, without interrupting. >> >> Mariano, the Ghost proxies are really great, only I think the logging >> should >> be optional and turned off by default. So it could be referenced by >> another >> project and ready to use. >> > > Indeed. I thought it was disabled by default. > > >> It's interesting to see the (no)difference between the debuggingMessages >> in >> Ghost, and these needed for ProtoObject subclass... :-) >> >> > It seems you were not the first fighting with that :) > Maybe it's time to document all this by having integrated in the image a > DebuggeableProtoObject? Subclass of ProtoObject and implementing the > needed > methods? > Those that could be implemented, can be implemented and those that would > depend on the usage, could be implemented as "self > subclassResponsability". > But what is important is that such a class will document the needed > methods > in order to proper debug/inspect subclasses of ProtoObject. I like the idea, but it doesn't depend on me... > Cheers, > > > >> Igor, you are right, the possibility to break something is not a bug, >> indeed >> :-) I know. >> >> >> >> >> ----- >> Save The World! >> -- >> View this message in context: >> http://forum.world.st/Debugger-recursion-tp4704703p4705487.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com ----- Save The World! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705815.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 30, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Aida 6.6 Web Framework Released

by Sven Van Caekenberghe

On 30 Aug 2013, at 15:47, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Dear Pharoers, > > New version of Aida/Web framework and application server > (http://www.aidaweb.si) is here with: > > - optimization on HTTP level to send first byte to the client as soon > as possible > - streaming of HTML, specially header to get first byte out > immediately, > - gzip compression of all text stuff like CSS, JS etc > - CSS Sprites support added > - internal vs. extarnal IP detection, to control access rights > accordingly > - Geolocation support improved > - all JS and CSS libraries updated to latest versions, Twitter > Bootstrap v3 added in parallel to v2.x Great work, thanks, Janko. Sven > More in Release notes: http://www.aidaweb.si/release-notes-6.6 > > On latest Pharo 2.0 open Configuration browser, right click and Switch > repository to SqueakSource. Select Aida and Install it. > > Or load Aida with this script: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfAida'; > load. > > (Smalltalk at: #ConfigurationOfAida) load. > > Then simply open http://localhost:8888 . > > Best regards > Janko > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

Aug. 30, 2013

[ANN] Aida 6.6 Web Framework Released

by Janko MivÅ¡ek

Dear Pharoers, New version of Aida/Web framework and application server (http://www.aidaweb.si) is here with: - optimization on HTTP level to send first byte to the client as soon as possible - streaming of HTML, specially header to get first byte out immediately, - gzip compression of all text stuff like CSS, JS etc - CSS Sprites support added - internal vs. extarnal IP detection, to control access rights accordingly - Geolocation support improved - all JS and CSS libraries updated to latest versions, Twitter Bootstrap v3 added in parallel to v2.x More in Release notes: http://www.aidaweb.si/release-notes-6.6 On latest Pharo 2.0 open Configuration browser, right click and Switch repository to SqueakSource. Select Aida and Install it. Or load Aida with this script: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Then simply open http://localhost:8888 . Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by Igor Stasenko

On 30 August 2013 13:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > you still do not believe me but I really think that wirting some documents > on > what are the practices > what ae the good practices > and what are the bad practices > is important just to make sure that people can refer to it in case. > > i didn't said i don't believe it. But what someone said (it was Esteban or someone else) in conversation, that existence of documentation does not guarantees there will be no abuses. Because , at the end, the developer can simply disagree with author's POV, and so he intentionally picks "not recommended" way. Of course it is not an excuse for not writing a documentation :) stef > > On Aug 30, 2013, at 1:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > the more i looking how people using announcements, the more it reminds me > the quote: > if the only *tool* you have is a *hammer*, to treat everything as if it > were a *nail* > > > On 30 August 2013 13:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 30 August 2013 13:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>> >>> On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: >>> >>> > can someone explain me, PLEASE, what is it for, >>> > and why there are announcer per each subclass of TestCase needed >>> > and why you organize it in a dictionary >>> >>> It should be a class side instance variable instead of a classVar that >>> maps test cases to announcer. >>> >> >> why? >> >> >>> Anyway the whole announcement stuff in SUnit is weird. >>> There TestAnnouncement (used by TestRunner) and an independent >>> TestCaseAnnouncement hierarchy (that nobody use). >>> And there is this TestAnnouncer that subclass SystemAnnouncer... >>> >>> that i already dealt with. >> >> But really.. why whole SUnit package needs more than one announcer >> announcing all events happening about running tests, >> why people so obsessive with announcers that they put them everywhere?? >> >> >> >>> > ... and.. do we need so many announcers >>> > everywhere? >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] NeoJSONCustomMapping>>#mapWithValueSchema:

by StÃ©phane Ducasse

sven can you add it to the readme so that when I turn it into a pier chapter we get it :) > Using the newly added NeoJSONCustomMapping>>#mapWithValueSchema: this is now possible, as the following unit test shows: > > testDictionaryOfObject2 > | data json reader | > data := Dictionary new. > data > at: #one put: NeoJSONTestObject2 example1; > at: #two put: NeoJSONTestObject2 example1. > json := NeoJSONWriter toString: data. > reader := NeoJSONReader on: json readStream. > reader for: #DictionaryOfObject2 customDo: [ :mapping | > mapping mapWithValueSchema: NeoJSONTestObject2 ]. > self > assert: (reader nextAs: #DictionaryOfObject2) > equals: data > > Note that the mapping mechanism in NeoJSON is optional. Without mapping you get Arrays and Dictionaries back, that you can then convert to your domain objects in the a next step. With mapping however, these intermediary representations are not used and maps or lists are parsed while creating and populating your domain objects directly, which should be more efficient. This does of course introduce the necessity of adding some form of static typing.

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by Camille Teruel

On 30 aoÃ»t 2013, at 13:38, Igor Stasenko wrote: > > > > On 30 August 2013 13:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: > > > can someone explain me, PLEASE, what is it for, > > and why there are announcer per each subclass of TestCase needed > > and why you organize it in a dictionary > > It should be a class side instance variable instead of a classVar that maps test cases to announcer. > > why? Just because if one wants one <whatever> per class, using a class-side inst var seems better than a class-<whatever> dictionary class var. But as you said, SUnit could use only one announcer anyway. > Anyway the whole announcement stuff in SUnit is weird. > There TestAnnouncement (used by TestRunner) and an independent TestCaseAnnouncement hierarchy (that nobody use). > And there is this TestAnnouncer that subclass SystemAnnouncer... > > that i already dealt with. > > But really.. why whole SUnit package needs more than one announcer announcing all events happening about running tests, > why people so obsessive with announcers that they put them everywhere?? Don't know, do a survey ;) > > > ... and.. do we need so many announcers > > everywhere? > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by StÃ©phane Ducasse

you still do not believe me but I really think that wirting some documents on what are the practices what ae the good practices and what are the bad practices is important just to make sure that people can refer to it in case. stef On Aug 30, 2013, at 1:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > the more i looking how people using announcements, the more it reminds me the quote: > if the only tool you have is a hammer, to treat everything as if it were a nail > > > On 30 August 2013 13:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 30 August 2013 13:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: > > > can someone explain me, PLEASE, what is it for, > > and why there are announcer per each subclass of TestCase needed > > and why you organize it in a dictionary > > It should be a class side instance variable instead of a classVar that maps test cases to announcer. > > why? > > Anyway the whole announcement stuff in SUnit is weird. > There TestAnnouncement (used by TestRunner) and an independent TestCaseAnnouncement hierarchy (that nobody use). > And there is this TestAnnouncer that subclass SystemAnnouncer... > > that i already dealt with. > > But really.. why whole SUnit package needs more than one announcer announcing all events happening about running tests, > why people so obsessive with announcers that they put them everywhere?? > > > > ... and.. do we need so many announcers > > everywhere? > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] SHA1 changed ??

by Sven Van Caekenberghe

On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> I'm not aware of such a change... >> this is probably an error/side effect of something else. >> > This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦ > > https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations I want to wait for Max to respond/explain. But according to http://en.wikipedia.org/wiki/Sha1 "SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long." The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash. >> Esteban >> >> On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Max, >>> >>> Why was the contract of SHA1>>hashStream: changed ? >>> >>> It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. >>> >>> MD5 hashMessage: 'foo'. >>> >>> #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] >>> >>> SHA1 hashMessage: 'foo'. >>> >>> 68123873083688143418383284816464454849230703155 >>> >>> It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. >>> >>> Can you please explain ? >>> >>> Sven >> >> >

Aug. 30, 2013

Re: [Pharo-dev] [update 3.0] #30359

by StÃ©phane Ducasse

I fixed it :) On Aug 30, 2013, at 9:28 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi, > > This image seems broken. > When I try to open the Monticello browser, I get PointPair(Object)>>doesNotUnderstand: #adaptToPoint:andSend: > In the stack, it is sent by Rectangle>>expandBy:. So maybe the fix for the issue 2489 is not fully working. > > Christophe. > > > Le 29 aoÃ»t 2013 Ã 22:22, StÃ©phane Ducasse a Ã©crit : > >> >> 30359 >> ----- >> >> - issue 2489 Strange Behavior of Rectangle Part Two >> https://pharo.fogbugz.com/default.asp?2489 >> >> - issue 11502 Override Class >> #setName: >> https://pharo.fogbugz.com/default.asp?11502 >> >> - issue 11505 Remove obsolete icons >> https://pharo.fogbugz.com/default.asp?11505 >> Diff information: >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-StephaneDucasse.1230.di… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDuc… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-StephaneDucass… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-StephaneDucasse.524.… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-StephaneDucasse.… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1585.d… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Tests-StephaneDucass… >> >> >

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by Igor Stasenko

the more i looking how people using announcements, the more it reminds me the quote: if the only *tool* you have is a *hammer*, to treat everything as if it were a *nail* On 30 August 2013 13:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 30 August 2013 13:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: >> >> > can someone explain me, PLEASE, what is it for, >> > and why there are announcer per each subclass of TestCase needed >> > and why you organize it in a dictionary >> >> It should be a class side instance variable instead of a classVar that >> maps test cases to announcer. >> > > why? > > >> Anyway the whole announcement stuff in SUnit is weird. >> There TestAnnouncement (used by TestRunner) and an independent >> TestCaseAnnouncement hierarchy (that nobody use). >> And there is this TestAnnouncer that subclass SystemAnnouncer... >> >> that i already dealt with. > > But really.. why whole SUnit package needs more than one announcer > announcing all events happening about running tests, > why people so obsessive with announcers that they put them everywhere?? > > > >> > ... and.. do we need so many announcers >> > everywhere? >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] SHA1 changed ??

by Marcus Denker

On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I'm not aware of such a change... > this is probably an error/side effect of something else. > This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦ https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations > Esteban > > On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Max, >> >> Why was the contract of SHA1>>hashStream: changed ? >> >> It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. >> >> MD5 hashMessage: 'foo'. >> >> #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] >> >> SHA1 hashMessage: 'foo'. >> >> 68123873083688143418383284816464454849230703155 >> >> It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. >> >> Can you please explain ? >> >> Sven > >

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by Igor Stasenko

On 30 August 2013 13:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: > > > can someone explain me, PLEASE, what is it for, > > and why there are announcer per each subclass of TestCase needed > > and why you organize it in a dictionary > > It should be a class side instance variable instead of a classVar that > maps test cases to announcer. > why? > Anyway the whole announcement stuff in SUnit is weird. > There TestAnnouncement (used by TestRunner) and an independent > TestCaseAnnouncement hierarchy (that nobody use). > And there is this TestAnnouncer that subclass SystemAnnouncer... > > that i already dealt with. But really.. why whole SUnit package needs more than one announcer announcing all events happening about running tests, why people so obsessive with announcers that they put them everywhere?? > > ... and.. do we need so many announcers > > everywhere? > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Aug. 30, 2013

Re: [Pharo-dev] SHA1 changed ??

by Esteban Lorenzano

I'm not aware of such a change... this is probably an error/side effect of something else. Esteban On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Max, > > Why was the contract of SHA1>>hashStream: changed ? > > It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. > > MD5 hashMessage: 'foo'. > > #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] > > SHA1 hashMessage: 'foo'. > > 68123873083688143418383284816464454849230703155 > > It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. > > Can you please explain ? > > Sven

Aug. 30, 2013

Re: [Pharo-dev] TestCase Announcers classvar is bizarre

by Camille Teruel

On 30 aoÃ»t 2013, at 13:16, Igor Stasenko wrote: > can someone explain me, PLEASE, what is it for, > and why there are announcer per each subclass of TestCase needed > and why you organize it in a dictionary It should be a class side instance variable instead of a classVar that maps test cases to announcer. Anyway the whole announcement stuff in SUnit is weird. There TestAnnouncement (used by TestRunner) and an independent TestCaseAnnouncement hierarchy (that nobody use). And there is this TestAnnouncer that subclass SystemAnnouncer... > ... and.. do we need so many announcers > everywhere? > > -- > Best regards, > Igor Stasenko.

Aug. 30, 2013

TestCase Announcers classvar is bizarre

by Igor Stasenko

can someone explain me, PLEASE, what is it for, and why there are announcer per each subclass of TestCase needed and why you organize it in a dictionary ... and.. do we need so many announcers everywhere? -- Best regards, Igor Stasenko.

Aug. 30, 2013

[update 3.0] #30360

by StÃ©phane Ducasse

Aug. 30, 2013

NeoJSONCustomMapping>>#mapWithValueSchema:

by Sven Van Caekenberghe

Hi, Sebastian asked me for a solution to the following problem: reading a JSON map where the values should be instances of a specific domain object. This was already possible for lists. Using the newly added NeoJSONCustomMapping>>#mapWithValueSchema: this is now possible, as the following unit test shows: testDictionaryOfObject2 | data json reader | data := Dictionary new. data at: #one put: NeoJSONTestObject2 example1; at: #two put: NeoJSONTestObject2 example1. json := NeoJSONWriter toString: data. reader := NeoJSONReader on: json readStream. reader for: #DictionaryOfObject2 customDo: [ :mapping | mapping mapWithValueSchema: NeoJSONTestObject2 ]. self assert: (reader nextAs: #DictionaryOfObject2) equals: data Note that the mapping mechanism in NeoJSON is optional. Without mapping you get Arrays and Dictionaries back, that you can then convert to your domain objects in the a next step. With mapping however, these intermediary representations are not used and maps or lists are parsed while creating and populating your domain objects directly, which should be more efficient. This does of course introduce the necessity of adding some form of static typing. http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo Sven

Aug. 30, 2013

Re: [Pharo-dev] SHA1 changed ??

by Damien Cassou

On Thu, Aug 29, 2013 at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to > make the code work on multiple Pharo versions. I have no idea about SHA1, and it may well be wrong. But you still probably don't need an ugly hack :-). You can always have your configuration load different versions of your code for different Pharo versions. (but it is time consuming). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 30, 2013

Re: [Pharo-dev] [update 3.0] #30359

by Christophe Demarey

Hi, This image seems broken. When I try to open the Monticello browser, I get PointPair(Object)>>doesNotUnderstand: #adaptToPoint:andSend: In the stack, it is sent by Rectangle>>expandBy:. So maybe the fix for the issue 2489 is not fully working. Christophe. Le 29 aoÃ»t 2013 Ã 22:22, StÃ©phane Ducasse a Ã©crit : > > 30359 > ----- > > - issue 2489 Strange Behavior of Rectangle Part Two > https://pharo.fogbugz.com/default.asp?2489 > > - issue 11502 Override Class >> #setName: > https://pharo.fogbugz.com/default.asp?11502 > > - issue 11505 Remove obsolete icons > https://pharo.fogbugz.com/default.asp?11505 > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-StephaneDucasse.1230.di… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDuc… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-StephaneDucass… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-StephaneDucasse.524.… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-StephaneDucasse.… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1585.d… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Tests-StephaneDucass… > >

Aug. 30, 2013

Re: [Pharo-dev] get an endless loop trying to get a menu on AbstractNautilusUI

by StÃ©phane Ducasse

I thought too. Before it was a DNU not a infinite loop. On Aug 30, 2013, at 8:27 AM, stleye(a)gmail.com wrote: > I'll fix it, I thought I already did it. > > > El 29/08/2013, a las 22:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > >> buildAnalyzeSubMenu: aBuilder >> <contextMenu> >> <nautilusGlobalClassMenu> >> | target | >> >> target := aBuilder model. >> target selectedClass ifNil: [^target]. >> target selectedClass buildAnalyzeSubMenu: aBuilder. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Now I do not get much how to fix it (too tired) >> >> Stef >> >

Aug. 30, 2013

Re: [Pharo-dev] get an endless loop trying to get a menu on AbstractNautilusUI

by stleye＠gmail.com

I'll fix it, I thought I already did it. El 29/08/2013, a las 22:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > buildAnalyzeSubMenu: aBuilder > <contextMenu> > <nautilusGlobalClassMenu> > | target | > > target := aBuilder model. > target selectedClass ifNil: [^target]. > target selectedClass buildAnalyzeSubMenu: aBuilder. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Now I do not get much how to fix it (too tired) > > Stef >

Aug. 30, 2013

[update 3.0] #30359

by StÃ©phane Ducasse

30359 ----- - issue 2489 Strange Behavior of Rectangle Part Two https://pharo.fogbugz.com/default.asp?2489 - issue 11502 Override Class >> #setName: https://pharo.fogbugz.com/default.asp?11502 - issue 11505 Remove obsolete icons https://pharo.fogbugz.com/default.asp?11505 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-StephaneDucasse.1230.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDuc… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-StephaneDucass… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-StephaneDucasse.524.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-StephaneDucasse.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1585.d… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Tests-StephaneDucass…

Aug. 29, 2013