- Pharo-dev - lists.pharo.org

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