- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo and Namespaces

by Torsten Bergmann

>Thanks for taking time at ESUG to listen and learn more about our namespace >proposal. I believe that we have cleared up some of the misconceptions >surrounding this complex topic. What was the outcome of the discussion? Does the proposal fit or not? What are the next steps? Thx T.

Sept. 24, 2012

[Pharo-project] Webcam + barcode

by Torsten Bergmann

I remeber Seabreeze for Seaside had some interface to webcam (using flash) and by using a webservice to decode barcodes. You can see it in action in the second video at the bottom of http://seabreeze.heeg.de/ A short description is here http://seabreeze.heeg.de/files/SBWebsiteFiles/seaBreeze.pdf Maybe the barcode widget is available in the MIT licensed open source distro (based on VisualWorks) Hope that helps! Bye T.

Sept. 24, 2012

Re: [Pharo-project] Pharo and Namespaces

by James Foster

Stef, Thanks for taking time at ESUG to listen and learn more about our namespace proposal. I believe that we have cleared up some of the misconceptions surrounding this complex topic. James On Jun 27, 2012, at 8:27 AM, StÃ©phane Ducasse wrote: > > On Jun 27, 2012, at 4:44 PM, James Foster wrote: > >> Stef, >> >> I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist. > > yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. > Now for 20 we should finish all the open tracks we have. > > Stef > >> >> Best wishes, >> >> James >> >> On Jun 27, 2012, at 12:08 AM, StÃ©phane Ducasse wrote: >> >>> James >>> >>> sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). >>> We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock >>> if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. >>> And yes I read the implementation two years ago. >>> Finally did you see the list of topics that I mention? >>> - do you want to help in any of them to make pharo better? >>> because we have to get them first and I need all my energy for them. >>> >>> Stef >>> >>> >>> On Jun 27, 2012, at 12:25 AM, James Foster wrote: >>> >>>> On Jun 26, 2012, at 12:51 PM, StÃ©phane Ducasse wrote: >>>> >>>>> On Jun 26, 2012, at 9:30 PM, James Foster wrote: >>>>> >>>>>> On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: >>>>>> >>>>>>>>>> What happened to the project from GermÃ¡n Leiva >>>>>>>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A >>>>>>>>> >>>>>>>>> we do not want class level namespace because this is the mess >>>>>>>> >>>>>>>> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. >>>>>>> >>>>>>> We do not want to have class name resolution at the granularity of a class. >>>>>> >>>>>> And are you saying this because you think GermÃ¡n's implementation does this? >>>>>> >>>>>>> Why because it means that in the same package reading the code containing a class Foo could be a different one. >>>>> >>>>>>> Why because it means that in the same package, reading the code containing a class Foo could be a different one. >>>>> ^^^^^ >>>>> >>>>> Class level namespace import means that in a given class, a method accessing the variable Foo may end up pointing to another class Foo in a class in the same package importing another namespace. >>>> >>>> I still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods. >>>> >>>> Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"? >>>> >>>>>> I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? >>>>> >>>>> No >>>>> I just say that changing binding of variables at the class level is not a good granularity. I do not want to have >>>>> >>>>> Object subclass: #NameOfSubclass >>>>> instanceVariableNames: '' >>>>> classVariableNames: '' >>>>> poolDictionaries: '' >>>>> category: 'Bob' >>>>>>>> environment: >>>> >>>> Is it your impression that GermÃ¡n's implementation requires this? If so, on what do you base that understanding? Have you looked at the code? >>>> >>>>>>> I'm saying that since years. >>>>>> >>>>>> I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. >>>>> >>>>> because this is a class level import. >>>> >>>> I still don't know what you mean by "class level import" or why you think GermÃ¡n's implementation fits your definition. >>>> >>>>>> Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. >>>>> >>>>> Usually this is the class of the method. >>>> >>>> By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime? >>>> >>>>>> This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. >>>>> >>>>> no this is a question of language design. >>>> >>>> Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug. >>>> >>>>>> In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) >>>>> >>>>> No we do not want to have that. >>>>> We want import to be specified at the border: i.e. during module import. Inside a module the world is flat and as a developer I do not want to know that this Point is from Core when that one is from MyCore. >>>> >>>> By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened? >>>> >>>>> If I want both, at the module import level I write >>>>> >>>>> Import: Point from: core as: CorePoint; >>>>> import: Point from: dev as: DevPoint; >>>> >>>> What object implements #'import:from:as:'? >>>> >>>>>> or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. >>>>> >>>>> I dislike them both. >>>>> A module should provide a certain level of encapsulation, else naming convention is good enough. >>>>> Because else having namespace does not prevent you to have to declare that WA is not a namespace somebody else should use. >>>> >>>> You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean. >>>> >>>> I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required. >>>> >>>> If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)? >>>> >>>> What I understand from your statements so far is that GermÃ¡n's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it? >>>> >>>> Thanks for engaging in the discussion. >>>> >>>> James Foster >>>> >>>> >>> >>> >>> >> >> > > >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Mariano Martinez Peck

On Mon, Sep 24, 2012 at 12:14 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > I still don't see the problem.... > > everything is symmetrical, everything works... > > Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups') ok we get the instance variables Nautilus class instVarNamed: 'groups' -> error For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent. Cheers, > > 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. > >> > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 24, 2012

Re: [Pharo-project] Bad behaviour at startup

by Mariano Martinez Peck

On Mon, Sep 24, 2012 at 10:44 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > The behavior you are seeing is standard behavior for a headless image, are > you running headless or not ? > I think that if the problem comes from the startUp processing, this is the standard behavior whether it is headless or not. But I may be wrong.... Igor/Esteban? I remember discussing this.... > > 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 > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 24, 2012

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

by Mariano Martinez Peck

On Mon, Sep 24, 2012 at 10:04 AM, Stephan Eggermont <stephan(a)stack.nl>wrote: > 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. > > Good point. Maybe it is time to move it to 2GB ? -- Mariano http://marianopeck.wordpress.com

Sept. 24, 2012

[Pharo-project] [update 2.0] #20305

by Marcus Denker

20305 ----- Issue 6647: Auto creation of Monticello packages (by RPackage ?) http://code.google.com/p/pharo/issues/detail?id=6647 Issue 6608: FileReference>>item http://code.google.com/p/pharo/issues/detail?id=6608 Issue 6605: Write Common UI Test http://code.google.com/p/pharo/issues/detail?id=6605 Issue 6655: SubscriptOutOfBounds: 1 when clearing a list in PluggableListMorph http://code.google.com/p/pharo/issues/detail?id=6655 -- Marcus Denker -- http://marcusdenker.de

Sept. 24, 2012

[Pharo-project] [update 2.0] #20304

by Marcus Denker

20304 ----- Issue 6721: Most Viewed Classes -> DNU http://code.google.com/p/pharo/issues/detail?id=6721 Issue 6704: Debugger looks for a context at index 0 http://code.google.com/p/pharo/issues/detail?id=6704 Issue 6385: Number date and time conversion should be an extension http://code.google.com/p/pharo/issues/detail?id=6385 -- Marcus Denker -- http://marcusdenker.de

Sept. 24, 2012

Re: [Pharo-project] StartupPreferences bug

by Guido Chari

Great! 2012/9/24 Guillermo Polito <guillermopolito(a)gmail.com> > > 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] Webcam + barcode

by laurent laffont

Thanks. Any code example to take shot from the webcam from Pharo ? Laurent On Mon, Sep 24, 2012 at 3:22 PM, S Krish <krishnamachari.sudhakar(a)gmail.com>wrote: > Take a bmp/ png save of the barcode.. and then you could easily use the > standard libs that decode a bitmap of a barcode > > Regular barcode scanner like function, I have not played with.. but could > work... on a loop call to the decoder with bitmaps sent every 1 sec.. as > you move the webcam.. for say 10 attempts.. exit if decoded. > > > > On Mon, Sep 24, 2012 at 5:22 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> 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