- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bad behaviour at startup

by Sven Van Caekenberghe

The behavior you are seeing is standard behavior for a headless image, are you running headless or not ? On 24 Sep 2012, at 10:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I am on Windows 7 > > 2012/9/24 Denis Kudriashov <dionisiydk(a)gmail.com> > Ok, I will look at mails. > > In short: > Start new seaside image. Add new zinc adaptor on port 10025 (for example). Save and close image. Block this port by firewall. Start image. > It should close immediately. > > I have pharoDebug with > THERE_BE_DRAGONS_HERE > Error: Cannot create socket on port 10025 > 24 September 2012 12:18:00.807 pm > > VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > Image: Pharo1.4 [Latest update: #14456] > > > > 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Check the mailing-list because this was already discussed. > igor and other spent time to streamline this process in particular in headless mode. > > So can you tell us a bit more what you are doing and when? > > Stef > > >> Hello. >> >> I found very bad behaviour. >> I use Pharo1.4. >> And when there is some errors at startup Image just closed. It is horrible >> >> I have image with seaside application which open socket at startup. >> So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. >> >> What you think about it? Is it fixed already at pharo 2.0? >> >> Best regards >> Denis >> >> > > > > On 24 Sep 2012, at 10:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I am on Windows 7 > > 2012/9/24 Denis Kudriashov <dionisiydk(a)gmail.com> > Ok, I will look at mails. > > In short: > Start new seaside image. Add new zinc adaptor on port 10025 (for example). Save and close image. Block this port by firewall. Start image. > It should close immediately. > > I have pharoDebug with > THERE_BE_DRAGONS_HERE > Error: Cannot create socket on port 10025 > 24 September 2012 12:18:00.807 pm > > VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > Image: Pharo1.4 [Latest update: #14456] > > > > 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Check the mailing-list because this was already discussed. > igor and other spent time to streamline this process in particular in headless mode. > > So can you tell us a bit more what you are doing and when? > > Stef > > > > Hello. > > > > I found very bad behaviour. > > I use Pharo1.4. > > And when there is some errors at startup Image just closed. It is horrible > > > > I have image with seaside application which open socket at startup. > > So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. > > > > What you think about it? Is it fixed already at pharo 2.0? > > > > Best regards > > Denis > > > > > > > > -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Igor Stasenko

On 24 September 2012 08:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote: > >> okay, i found what is wrong with first post (didn't read carefully). >> >> The instVarNames is a class-side protocol i.e. part of a class behavior, >> while instVarNamed: is an instance-side protocol i.e. "hackishly >> access to instance variable with given name" > > Yes this is exactly my point. > I think that there is a protocol missing for class to be consistent. > err, what is missing? class is an object, and using #instVarNamed: on them is perfectly fine. >> So, this is ok: >> Nautilus class instVarNames >> -> #('maxSize' 'cachedLastClasses' 'groups') >> >> And this is ok too: >> >> Nautilus instVarNamed: 'groups' >> worked >> >> because Nautilus is an instance of its metaclass. >> >> But this is wrong, since 'Nautilus class' is an instance of Metaclass, >> and metaclass doesn't have 'groups' variable. >> >> Nautilus class instVarNamed: 'groups' >> -> error >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Sept. 24, 2012

Re: [Pharo-project] StartupPreferences bug

by Guillermo Polito

I'm looking forward to integrate this :) On Thu, Sep 20, 2012 at 4:42 PM, Guido Chari <charig(a)gmail.com> wrote: > Mariano! > > Yes, i'm seeing the same on last 2.0. I've made a little add-on for > writing startup rules modular on the image and then a builder that generate > startup files from those methods and i had to rollback to previous versions > of the method i said for being able to store the rules on files. > > Cheers, > Guido. > > 2012/9/20 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Hi Guido. Is this still a problem? >> >> >> On Wed, Aug 22, 2012 at 4:40 PM, Guido Chari <charig(a)gmail.com> wrote: >> >>> There was a change on the storeOn: method of StartupAction that is >>> breaking things. Before it said: " aStream >> code printString" and now it >>> has "code storeOn: aStream". I'm almost sure that the previous one is the >>> correct one. We didn't one to print the object on the file, only the text >>> for later running it or am i wrong? >>> >>> Cheers, >>> Guido. >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

Sept. 24, 2012

Re: [Pharo-project] Bad behaviour at startup

by Denis Kudriashov

I am on Windows 7 2012/9/24 Denis Kudriashov <dionisiydk(a)gmail.com> > Ok, I will look at mails. > > In short: > Start new seaside image. Add new zinc adaptor on port 10025 (for example). > Save and close image. Block this port by firewall. Start image. > It should close immediately. > > I have pharoDebug with > THERE_BE_DRAGONS_HERE > Error: Cannot create socket on port 10025 > 24 September 2012 12:18:00.807 pm > > VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 > uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, > StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: > 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, > https://git.gitorious.org/cogvm/blessed.git Commit: > 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 > +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > Image: Pharo1.4 [Latest update: #14456] > > > > 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> Check the mailing-list because this was already discussed. >> igor and other spent time to streamline this process in particular in >> headless mode. >> >> So can you tell us a bit more what you are doing and when? >> >> Stef >> >> >> > Hello. >> > >> > I found very bad behaviour. >> > I use Pharo1.4. >> > And when there is some errors at startup Image just closed. It is >> horrible >> > >> > I have image with seaside application which open socket at startup. >> > So when I move to another computer where this port is busy (or closed >> by firewall) Pharo opened and immediately closed. No chance to debug and >> fix it. >> > >> > What you think about it? Is it fixed already at pharo 2.0? >> > >> > Best regards >> > Denis >> > >> > >> >> >> >

Sept. 24, 2012

Re: [Pharo-project] Bad behaviour at startup

by Denis Kudriashov

Ok, I will look at mails. In short: Start new seaside image. Add new zinc adaptor on port 10025 (for example). Save and close image. Block this port by firewall. Start image. It should close immediately. I have pharoDebug with THERE_BE_DRAGONS_HERE Error: Cannot create socket on port 10025 24 September 2012 12:18:00.807 pm VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Image: Pharo1.4 [Latest update: #14456] 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Check the mailing-list because this was already discussed. > igor and other spent time to streamline this process in particular in > headless mode. > > So can you tell us a bit more what you are doing and when? > > Stef > > > > Hello. > > > > I found very bad behaviour. > > I use Pharo1.4. > > And when there is some errors at startup Image just closed. It is > horrible > > > > I have image with seaside application which open socket at startup. > > So when I move to another computer where this port is busy (or closed by > firewall) Pharo opened and immediately closed. No chance to debug and fix > it. > > > > What you think about it? Is it fixed already at pharo 2.0? > > > > Best regards > > Denis > > > > > > >

Sept. 24, 2012

[Pharo-project] Default max heap size on OS-X

by Stephan Eggermont

Hi I noticed the default SqueakMaxHeapSize on CI for Mac is 536870912 bytes. Is there a specific reason for the default to be so low? I know there used to be problems with the windows vm. Stephan

Sept. 24, 2012

Re: [Pharo-project] Bad behaviour at startup

by StÃ©phane Ducasse

Check the mailing-list because this was already discussed. igor and other spent time to streamline this process in particular in headless mode. So can you tell us a bit more what you are doing and when? Stef > Hello. > > I found very bad behaviour. > I use Pharo1.4. > And when there is some errors at startup Image just closed. It is horrible > > I have image with seaside application which open socket at startup. > So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. > > What you think about it? Is it fixed already at pharo 2.0? > > Best regards > Denis > >

Sept. 24, 2012

[Pharo-project] Bad behaviour at startup

by Denis Kudriashov

Hello. I found very bad behaviour. I use Pharo1.4. And when there is some errors at startup Image just closed. It is horrible I have image with seaside application which open socket at startup. So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. What you think about it? Is it fixed already at pharo 2.0? Best regards Denis

Sept. 24, 2012

Re: [Pharo-project] Changes in MongoTalk

by StÃ©phane Ducasse

if the volume gets annoying we will tell you. for now talk here :) On Sep 24, 2012, at 8:17 AM, Francois Stephany wrote: > >> Next on my list: numberToSkip[1]. With "limit" and "numberToSkip", we >> should be able to have something like pagination easily. > > Done. > Once again, stop me if I'm doing stupid stuff :p > > Is there a dedicated place to talk about Mongo/Voyage? I feel like I'm polluting the pharo ML... >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote: > okay, i found what is wrong with first post (didn't read carefully). > > The instVarNames is a class-side protocol i.e. part of a class behavior, > while instVarNamed: is an instance-side protocol i.e. "hackishly > access to instance variable with given name" Yes this is exactly my point. I think that there is a protocol missing for class to be consistent. > So, this is ok: > Nautilus class instVarNames > -> #('maxSize' 'cachedLastClasses' 'groups') > > And this is ok too: > > Nautilus instVarNamed: 'groups' > worked > > because Nautilus is an instance of its metaclass. > > But this is wrong, since 'Nautilus class' is an instance of Metaclass, > and metaclass doesn't have 'groups' variable. > > Nautilus class instVarNamed: 'groups' > -> error > > > -- > Best regards, > Igor Stasenko. >

Sept. 24, 2012