September 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Webcam + barcode

by laurent laffont

Hi, I would like to scan a barcode with a webcam and get the ISBN of a book. Any help ? Cheers, Laurent

Sept. 24, 2012

[Pharo-project] [update 2.0] #20301

by Esteban Lorenzano

2.0.20301 --------- The following changes have been integrated: Issue 6728: infinite recursion on startup preferences. http://code.google.com/p/pharo/issues/detail?id=6728 Issue 6723: Improve Collection Streaming http://code.google.com/p/pharo/issues/detail?id=6723 Issue 6715: RPackageSet is not backwards compatible http://code.google.com/p/pharo/issues/detail?id=6715

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

I still don't see the problem.... everything is symmetrical, everything works... On 2012-09-24, at 11:18, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > ...makes me envy the simplicity of SELF! > > Fernando > > On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> 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] instVarNames vs instVarNamed:

by Fernando Olivero

...makes me envy the simplicity of SELF! Fernando On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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] Bad behaviour at startup

by Denis Kudriashov

Of course not. Image is just usual image, not headless. When it starts I see all my browsers and workspaces but then it closed with PharoDebug report. Evening I will try such scenario at latest pharo2.0 <http://lingvopro.abbyyonline.com/ru/Search/GlossaryItemExtraInfo?text=%d0%b…> 2012/9/24 Sven Van Caekenberghe <sven(a)stfx.eu> > 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] StartupPreferences bug

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=&colsp… On Mon, Sep 24, 2012 at 10:37 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > 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 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