- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Connection closed while waiting for data in bootstrapped image

by Sven Van Caekenberghe

Hi Pavel, On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Sven, > > we can successfully load network packages to the bootstrapped image but when we try to test it using: > > ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. > > we get "ConnectionClosed: Connection closed while waiting for data" error after few seconds. Do you have some idea, what may be wrong? Probably something is not initialized well but I have no clue what. > > Cheers, > -- Pavel Hard to say. I would guess that you are already on the point of waiting for a server response, so you already successfully initialised networking, resolved DNS, opened a TCP socket and wrote the request over it. On the other hand, one of those steps might not have been done right, since you get no response. Any chance of a stack trace ? Or an image ? But that would be a headless one I guess ;-) Sven

Feb. 16, 2014

Pharo 3 - Nautilus bug ?

by jannik laval

When browsing class extensions, when I have an extension in instance side and an extension in class side, this class appears 2 times in the browser. See attached screenshot. [image: Images intÃ©grÃ©es 1] -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

Feb. 16, 2014

Connection closed while waiting for data in bootstrapped image

by Pavel Krivanek

Hi Sven, we can successfully load network packages to the bootstrapped image but when we try to test it using: ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. we get "ConnectionClosed: Connection closed while waiting for data" error after few seconds. Do you have some idea, what may be wrong? Probably something is not initialized well but I have no clue what. Cheers, -- Pavel

Feb. 16, 2014

Re: [Pharo-dev] Dirty Seaside-pharo-core and Seaside-pharo-core-backtracking

by Sven Van Caekenberghe

On 16 Feb 2014, at 20:58, Johan Brichau <johan(a)inceptive.be> wrote: > It seems there were still some class extensions in the package Seaside-Pharo20-Core that were using the '*seaside-pharo-core' method protocol name. > This is because the package was originally just a copy of the Seaside-Pharo-Core package, and there was a (now solved) bug in Nautilus at the time the package was renamed. > > It's fixed now in the #bleedingEdge Yes it is, thank you ! > Johan > > On 16 Feb 2014, at 15:26, Max Leske <maxleske(a)gmail.com> wrote: > >> Hmâ¦ donât really know but I guess they could come fromt the configuration. If you look for the string âseaside-pharoâ in the image then youâll see that those packages are specified in the configuration. But if you really want to know youâll probably have to step through a loading cycle with Metacelloâ¦ good luck with that :) >> >> >> On 16.02.2014, at 14:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> As far as I can see, there is no such package, at all, that is why I am puzzled ;-) >>> >>> On 16 Feb 2014, at 14:50, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> If youâve loaded Seaside-Pharo then those extensions would be in the Seaside-Pharo package, wouldnât they? >>>> >>>> >>>> On 16.02.2014, at 14:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> When using the latest Seaside on Pharo 3 (either loading ConfigurationOfBootstrap or the Seaside image, 3.0 bleedingEdge, built on the pharo-contribution CI server), I have two mysterious dirty packages without a repository: >>>>> >>>>> - Seaside-pharo-core >>>>> - Seaside-pharo-core-backtracking >>>>> >>>>> These only contain extensions. There are no such Seaside package as far as I can see. >>>>> >>>>> What puzzles me is how the code got in the image in the first place: I can understand that these are possible wrong extension protocol names, but since they must be loaded by an MC package, how did they get into that package in the first place ? >>>>> >>>>> Sven >>>>> >>>>> -- >>>>> Sven Van Caekenberghe >>>>> http://stfx.eu >>>>> Smalltalk is the Red Pill >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Feb. 16, 2014

Re: [Pharo-dev] List methods with problematic source

by Sebastian Sastre

awesome! thanks Sean sebastian o/ > On 16/02/2014, at 16:47, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > sebastian(a)flowingconcept.com wrote >> How can I collect a list of methods with undefined classes in its source? > > Try the Critics Browser. I simulated by creating a method that referenced a > class that I subsequently deleted, and the "Variable used, but not defined > anywhere" rule caught it. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/List-methods-with-problematic-source-tp4744083p474416… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 16, 2014

Re: [Pharo-dev] Dirty Seaside-pharo-core and Seaside-pharo-core-backtracking

by Johan Brichau

It seems there were still some class extensions in the package Seaside-Pharo20-Core that were using the '*seaside-pharo-core' method protocol name. This is because the package was originally just a copy of the Seaside-Pharo-Core package, and there was a (now solved) bug in Nautilus at the time the package was renamed. It's fixed now in the #bleedingEdge Johan On 16 Feb 2014, at 15:26, Max Leske <maxleske(a)gmail.com> wrote: > Hmâ¦ donât really know but I guess they could come fromt the configuration. If you look for the string âseaside-pharoâ in the image then youâll see that those packages are specified in the configuration. But if you really want to know youâll probably have to step through a loading cycle with Metacelloâ¦ good luck with that :) > > > On 16.02.2014, at 14:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> As far as I can see, there is no such package, at all, that is why I am puzzled ;-) >> >> On 16 Feb 2014, at 14:50, Max Leske <maxleske(a)gmail.com> wrote: >> >>> If youâve loaded Seaside-Pharo then those extensions would be in the Seaside-Pharo package, wouldnât they? >>> >>> >>> On 16.02.2014, at 14:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> When using the latest Seaside on Pharo 3 (either loading ConfigurationOfBootstrap or the Seaside image, 3.0 bleedingEdge, built on the pharo-contribution CI server), I have two mysterious dirty packages without a repository: >>>> >>>> - Seaside-pharo-core >>>> - Seaside-pharo-core-backtracking >>>> >>>> These only contain extensions. There are no such Seaside package as far as I can see. >>>> >>>> What puzzles me is how the code got in the image in the first place: I can understand that these are possible wrong extension protocol names, but since they must be loaded by an MC package, how did they get into that package in the first place ? >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>>> >>> >>> >> >> > >

Feb. 16, 2014

Re: [Pharo-dev] List methods with problematic source

by Sean P. DeNigris

sebastian(a)flowingconcept.com wrote > How can I collect a list of methods with undefined classes in its source? Try the Critics Browser. I simulated by creating a method that referenced a class that I subsequently deleted, and the "Variable used, but not defined anywhere" rule caught it. ----- Cheers, Sean -- View this message in context: http://forum.world.st/List-methods-with-problematic-source-tp4744083p474416… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 16, 2014

Re: [Pharo-dev] [squeak-dev] SqueakSSL fixes

by GÃ¶ran Krampe

On 02/16/2014 08:08 PM, Sven Van Caekenberghe wrote: > Hi GÃ¶ran, > > Thanks a lot, I've turned your email into a Pharo issue: > > https://pharo.fogbugz.com/f/cases/12894/SSL-plugin-enhancements > > I won't be able to process this by myself, but it will get integrated once the right people get together. No problemo, thanks! regards, GÃ¶ran

Feb. 16, 2014

Re: [Pharo-dev] [squeak-dev] SqueakSSL fixes

by Sven Van Caekenberghe

Hi GÃ¶ran, Thanks a lot, I've turned your email into a Pharo issue: https://pharo.fogbugz.com/f/cases/12894/SSL-plugin-enhancements I won't be able to process this by myself, but it will get integrated once the right people get together. Sven On 13 Feb 2014, at 13:00, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hey! > > Ok, so I sat down and "packaged" some fixes to mainly iOS SqueakSSL that we have done here at 3DICC. We have no intention to keep stuff like this for ourselves, but daily we work using our own repos so it needs some attention and time to get it out there :) > > Sorry if this email is long but I just wanted to make it easy for people to know how to integrate this. > > The fixes span: > > * A new SqueakSSL Monticello package, that has other fixes too done at 3DICC. I haven't looked through them all in detail, so here a bit of manual cherry picking is needed. For example we removed some "compatibility code" for Squeak 4.2 causing us some problems. > > * Modified platform files: > platforms/Cross/plugins/SqueakSSL/SqueakSSL.h > platforms/iOS/plugins/SqueakSSL/sqMacSSL.c > platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.c > platforms/win32/plugins/SqueakSSL/sqWin32SSL.c > > I have so far only tested the new sqMacSSL.c on iOS - OSX 10.8.5. > The changes in the other platforms are not complicated, its about being able to disable certificate check mainly so I don't think they should fail. > > As of now SqueakSSL-Tests show 14 run, 3 passes, 8 expected failures and 3 errors on my Mac. The errors still left are: testSSLSockets, testSocketAccept, testSocketConnect. AFAIK all these try to use a test certificate and Accept - and *that* I haven't implemented on Mac (well, ok, I started - there is a way to at least set a Mac test cert into the plugin - but I didn't go further). > > New methods in the classes: > > SqueakSSL,SecureSocketStream>>certVerify: aBoolean > Now one can tell the plugin to verify certs or just skip that. > > SqueakSSL,SecureSocketStream>>logLevel: anInteger > Now one can set the logLevel in the plugin, 0 or 1 so far. > > > Attached ssl-fix.zip which contains: > . > âââ platforms > â âââ Cross > â â âââ plugins > â â âââ SqueakSSL > â â âââ SqueakSSL.h > â âââ iOS > â â âââ plugins > â â âââ SqueakSSL > â â âââ sqMacSSL.c > â âââ unix > â â âââ plugins > â â âââ SqueakSSL > â â âââ sqUnixOpenSSL.c > â âââ win32 > â âââ plugins > â âââ SqueakSSL > â âââ sqWin32SSL.c > âââ SqueakSSL-Core-gk.36.mcz > âââ SqueakSSL-Tests-ar.17.mcz > âââ ssl-fix.patch > > I threw in the latest SqueakSSL-Core and Tests that we have here at 3DICC. The Tests package is the same as on SS. The Core has 4 more fixes from Ron I think, just look in "History" to see commit messages there. > > ssl-fix.patch - this should show you what I have done in the platform files, and I produced it using git diff on those four files with this command: > > git diff 83bce99715cddd8a82c3d94c487e45ec0213be19 platforms/Cross/plugins/SqueakSSL/SqueakSSL.h platforms/iOS/plugins/SqueakSSL/sqMacSSL.c platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.c platforms/win32/plugins/SqueakSSL/sqWin32SSL.c > ssl-fix.patch > > The SHA is: > > commit 83bce99715cddd8a82c3d94c487e45ec0213be19 > Author: Camillo Bruni <camillobruni(a)gmail.com> > Date: Fri Nov 15 12:24:11 2013 +0100 > > fixed wrong path > ------------------------------ > > > ...phew. Ok, let me know if you need anything more and ask questions. > > regards, GÃ¶ran > > <ssl-fix.zip>

Feb. 16, 2014

Re: [Pharo-dev] 100% CPU usage on image resume

by Sven Van Caekenberghe

Hi Holger, I make an issue out of this (I hope you can access this): https://pharo.fogbugz.com/f/cases/12893/100-CPU-usage-on-image-resume but... [ [ Transcript crShow: DateAndTime now. 5 seconds asDelay wait ] repeat ] fork. works for me (Pharo #30754, Mac OS X), so please, come up with a failing example, else I'll have to close the issue again. Sven On 13 Feb 2014, at 08:44, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: > On Wed, Feb 12, 2014 at 03:31:56PM +0100, Sven Van Caekenberghe wrote: >> Holger, > > Dear Sven, > > thanks a lot for your answer. > >>> The entire process list is below. My assumption is that the >>fireTimers: >>> method is actually being executed. The best thing I found was to use SIGUSR1 >>> to sample which processes run. My assumption is that this process runs before >>> DateAndTime has been re-initialized by the SmalltalkImage. > > >> >> Now, you do agree that you are doing tricky stuff, right ? You play with timers, timestamps and delays in a process that you expect to keep running over image save/resume ;-) > > The timers work with absolute time and the code is working fine with GNU > Smalltalk for years (with image save/resume). I think the only thing weird > in Pharo is that (Delay forSeconds: 1) wait will wait forever on image > resume but IIRC this is a known issue/feature. > >> >> I think a better approach would be to subscribe to image #shutDown: and #startUp: events (trace these selectors for examples). With these you can cleanly stop your process on image save and restart it when the image resumes. I think all long running processes work that way. > > > I have implemented your proposal and I think the problem will go away > with that. To me this sounds a bit like a work-around. Do you agree? I > think something like: > > [[DateAndTime now] repeat] fork > > could re-produce the issue. It can either get stuck inside the Delay > created from within >>#now or in this mysterious loop that takes all the > CPU and doesn't allow me to interact with the image anymore. It would be > nice to fully understand why this process runs away and no other process > will be scheduled. > > I don't know how the ProcessorScheduler works in Pharo and when/if a > method is pre-empted. Is there any guarantee that the StartUpList will > be executed before any other process will be scheduled? From quick browsing > it seems that the SmalltalkImage code does not suspend all the other > processes? > > kind regards > holger >

Feb. 16, 2014