June 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] SUNIT Framework

by sourav roy

hiI am in need of some good referance meterials with some realistic examples on SUNIT framework for VA Smalltalk or Pharo.Thanks Sourav BangaloreIndia

June 28, 2011

Re: [Pharo-project] Please test Pharo 1.3!

by Janko MivÅ¡ek

Hi Torsten, S, Torsten Bergmann piÅ¡e: >> Or maybe introducing Help -> About in world menu? Or both... > > Try System->About in the world menu Ahh, I'm used on all other programs to find it under Help menu. Even that under System is more appropriate, a normal user is more used to have under Help, and as we like to say: "habit is an iron shirt"... But this is an usability thought for 1.4, sorry to bother you now :) Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Igor Stasenko

On 28 June 2011 11:43, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > Ok, thank you henrik. > So I understand well that the announcement delivery handler will recast in > new thread. The point I do not get (and maybe its obvious, sorry in > advance), is why does it raise an error ? > When I look at the debugger, it seems that at one moment in the on:fork: > method we got a 'context' that is nil whereas it should not. > It is quite to understand what is problem (As I do not have a lot of > knowledge around that) > What VM you using? Can you try running using other VM? > 2011/6/28 Henrik Johansen <henrik.s.johansen(a)veloxit.no> >> >> On Jun 28, 2011, at 10:23 56AM, Cyrille Delaunay wrote: >> >> I got another issue related to that i think. >> In moose , at one moment in a announcement handling code, we are >> Â doing:Â Notification signal: 'Save successful!'. >> That has for consequence that the on:fork: cuts the stack and I end up >> with a 'MessageNotUnderstood: receiver of "sender" is nil'. >> So I don't know if the problem is that we are signaling a notification? >> >> Yes, if nothing inside the announcement handling code handles it, it will >> get handled by the announcement delivery handler which recasts it in new >> thread, for the reason Igor mentioned below. >> It's not safe to simply pass it on for handling by the code that made the >> announcement, if you want to ensure delivery. >> >> if yes what should we use to notify something ? >> >> ... an Announcement? >>> >>> It was because on:fork: cuts the stack. >>> If you signaling exception in your code, you should handle it before >>> leaving your #actionSelector method. >>> Otherwise you may put the rest recipients of announcement in danger >>> and that's why there #on:fork: to prevent that. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> Cheers, >> Henry > -- Best regards, Igor Stasenko AKA sig.

June 28, 2011

[Pharo-project] Please test Pharo 1.3!

by Torsten Bergmann

Hi Janko, >Or maybe introducing Help -> About in world menu? Or both... Try System->About in the world menu Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

June 28, 2011

Re: [Pharo-project] [Jenkins] Kernel 1.4 with Gofer+Networking

by Marcus Denker

On Jun 28, 2011, at 8:42 AM, Pavel Krivanek wrote: > Well, the size is so big because loading of packages worked well but > initialization step that does cleanup failed. Change this: > > line 76: > accuny := Compiler evaluate: (FileStream readOnlyFileNamed: > 'accuny.txt') contentsOfEntireFile. > > line 263: > rep := FileStream forceNewFileNamed: 'PharoDebug.log'. > > ...or use the attached file. Evidently a mess in versions, I think my fault. > done > In the file loadCore.st remove the line 70 that makes the package > Deprecated12 part of the Core image to be up-to-date with current > verson Ok. And we need to change to load from SqueakSource "Pharo14" (but I need to make sure to have actually the last version there copied...) We changed to a new Dir because just getting the list of mcz files is getting too slow for the Pharo Project (>4000 files). -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 28, 2011

Re: [Pharo-project] Please test Pharo 1.3!

by Janko MivÅ¡ek

Hi Marcus, Aida works ok. One suggestion: put version number somewhere near Pharo logo in main window. Otherwise is pretty hard to recognize on which image version you are working. Or maybe introducing Help -> About in world menu? Or both... Thanks and best regards Janko S, Marcus Denker piÅ¡e: > Please test Pharo 1.3! > > There is no magic.. what is now here: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/ > > Will be the release. Issues fixed until the released are just those that will be detected and fixed. > > There is no magic. > > For those who only run released software: Version Number is 1.3. Consider this released. There will be no RC. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

June 28, 2011

Re: [Pharo-project] About HTTP proxies, settings and MacOS

by Sven Van Caekenberghe

On 28 Jun 2011, at 11:12, Marcus Denker wrote: > InternetConfiguration>>startUp > OSPlatform isMacOS ifTrue: [ > self useHTTPProxy ifTrue: [ > (self getHTTPProxyHost findTokens: ':') ifNotEmpty: [:p | > HTTPSocket useProxyServerNamed: p first port: p second asInteger]]] After browsing the code a bit, adding NetworkSystemSettings useHTTPProxy: true inside the ifNotEmpty: as last statement might already help. It would be cleaner to no longer reference HTTPSocket here and add use NetworkSystemSettings. The silly thing is that currently, NetworkSystemSettings itself falls back to HTTPSocket for the proxy host and port, for backwards compatibility reasons no doubt. Still, the abstraction/indirection would be good. So then it the code would be NetworkSystemSettings httpProxyServer: p first; httpProxyPort: p second asInteger; useHTTPProxy: true As sole contents of the ifNotEmpty: But since I am not behind a proxy, this must still be tested by someone who is. Regards, Sven

June 28, 2011

Re: [Pharo-project] [Jenkins] Kernel 1.4 with Gofer+Networking

by Marcus Denker

On Jun 27, 2011, at 1:16 PM, Marcus Denker wrote: > > On Jun 27, 2011, at 1:10 PM, Pavel Krivanek wrote: > >> Hi, >> >> should I prepare ImageMap generation for the Kernel too? The problem >> is that the generation takes quite long time (up to 20 min.) and the >> generated HTML files are quite big too (about 80MB). On the other >> hand, it is good test of the good fitness of the image. >> > > We can make another Jenkins Project (Kernel-Report) for this... than the execution time > is not a problem. > Online: https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Report/lastSuccessfulB… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Cyrille Delaunay

Ok, thank you henrik. So I understand well that the announcement delivery handler will recast in new thread. The point I do not get (and maybe its obvious, sorry in advance), is why does it raise an error ? When I look at the debugger, it seems that at one moment in the on:fork: method we got a 'context' that is nil whereas it should not. It is quite to understand what is problem (As I do not have a lot of knowledge around that) 2011/6/28 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Jun 28, 2011, at 10:23 56AM, Cyrille Delaunay wrote: > > I got another issue related to that i think. > In moose , at one moment in a announcement handling code, we are > doing: Notification signal: 'Save successful!'. > That has for consequence that the on:fork: cuts the stack and I end up with > a 'MessageNotUnderstood: receiver of "sender" is nil'. > So I don't know if the problem is that we are signaling a notification? > > > Yes, if nothing inside the announcement handling code handles it, it will > get handled by the announcement delivery handler which recasts it in new > thread, for the reason Igor mentioned below. > It's not safe to simply pass it on for handling by the code that made the > announcement, if you want to ensure delivery. > > > if yes what should we use to notify something ? > > > ... an Announcement? > > It was because on:fork: cuts the stack. >> If you signaling exception in your code, you should handle it before >> leaving your #actionSelector method. >> Otherwise you may put the rest recipients of announcement in danger >> and that's why there #on:fork: to prevent that. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > Cheers, > Henry >

June 28, 2011

Re: [Pharo-project] About HTTP proxies, settings and MacOS

by Sven Van Caekenberghe

On 28 Jun 2011, at 11:12, Marcus Denker wrote: > We need to rewrite this: > > InternetConfiguration>>startUp > OSPlatform isMacOS ifTrue: [ > self useHTTPProxy ifTrue: [ > (self getHTTPProxyHost findTokens: ':') ifNotEmpty: [:p | > HTTPSocket useProxyServerNamed: p first port: p second asInteger]]] > > For Zinc. Since (which is now in 1.3 already): --- Name: Zinc-HTTP-SvenVanCaekenberghe.164 Author: SvenVanCaekenberghe Time: 17 June 2011, 9:16:22 am UUID: 90d57d3d-fc41-4548-a2fd-dcd7c22a3a1f Ancestors: Zinc-HTTP-SvenVanCaekenberghe.163 implemented support for proxies that require authorization; ZnHeaders class>>#requestHeadersFor: will add a Proxy-Authorization header when needed; added public API ZnNetworkingUtils class>>#proxyAuthorizationHeaderValueToUrl: removed public API ZnNetworkingUtils class>>#httpProxy and #isProxySet; upgraded public API ZnNetworkingUtils class>>#shouldProxyUrl: to be a primary interface; refactored internals of ZnNetworkUtils to use NetworkSystemSettings directly instead of HTTPSocket; this code still has to be tested and validated with real world proxies --- Zn is no longer using HTTPSocket as authorative source for the proxy settings info, but is using NetworkSystemSettings. This was necessary to get the info for authenticated proxies. Also, we should not depend on HTTPSocket if we can avoid it. So yes, it seems as if the code that Marcus showed needs to modify NetworkSystemSettings, which would fix Mariono's issues. Sven

June 28, 2011