July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] How important is ANSI Smalltalk / speeding up ASCII/Latin1/Unicode I/O

by Philippe Marschall

Dave Mason wrote: > I have been wondering about ways to speed up character-set > conversions, and related I/O as mentioned in the recent email about > MultiByteFileStream. However this change might break parts of the > ANSI Smalltalk hierarchy - particularly around String. Important for Seaside, we use the utf8 fastpath by Andreas instead of Utf8TextConverter for this reason. > So my question is, how important is ANSI compatibility? Squeak? GNU > Smalltalk? VW? VA? What do you have in mind? In general ANSI compatibility is important for Seaside. Cheers Philippe

July 23, 2009

Re: [Pharo-project] [ANN] Dependency Browser update

by HernÃ¡n Morales Durand

Hi Simon, 2009/7/22 Simon Denier <Simon.Denier(a)inria.fr> > Hi Hernan > > That's a pretty neat tool, very professional. I would vote for its > inclusion in an extended Pharo for developers. Thanks, I'm very glad if the DependencyBrowser result in a useful tool for somebody. > But you know what would be even cooler? If you can take into account > the explicit dependencies of Monticello packages and highlight in red > those non-system packages which are not explicitly declared as > dependencies i.e. packages which would failed if loaded in a fresh > image because of missing implicit dependencies. That's a good usability idea. I will let you know when it's ready, right now with the latest OmniBrowser, I see no protocol for changing the foreground color of a node in the OBNode hierarchy. Perhaps another OB user could tell how to do it? Cheers. HernÃ¡n

July 23, 2009

[Pharo-project] AbstractResizerMorph>>handlesMouseUp: redundant

by Igor Stasenko

this message is never sent. In fact, one should answer true to #handlesMouseDown: to receive mouseUp events as well. -- Best regards, Igor Stasenko AKA sig.

July 23, 2009

Re: [Pharo-project] The Pharo Toolset Guide (request)

by Schwab,Wilhelm K

Esteban, Take a look at http://squeakbyexample.org Its description of Monticello is probably the best you will find. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban A. Maringolo Sent: Wednesday, July 22, 2009 7:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] The Pharo Toolset Guide (request) Hi, As I told, I'm new to this squeak/pharo world, particulary in relation with its toolset. I'm developing, and by now I was using fileOut/fileIn to manage, save, version, etc my codebase. I would like to know how to create a Monticello repository to host my projects, how to create a package for them, etc. I know there are many versions around, and don't know which is the one in use in the latest Pharo core. Is there a "terse guide" to get a smalltalker coming from other smalltalk to understand the phylosophy behind the Pharo tools, and how to use them? Besides http://www.wiresong.ca/Monticello/UserManual/, is there any other resource I should be aware to learn the mentioned above? Best regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2009

Re: [Pharo-project] Author class

by HernÃ¡n Morales Durand

You should excuse me. What follows is a combination of wishful thinking and inquiry, and I really don't know if there's place or interest in this kind of discussion here. An Author should be an object. Right? Because a String or an "annotation" is not the most accurate concept that describes you in the system, and I know smalltalkers which feel a subtle ontological degradation when they realize they are not an object :) But, what is an Author anyway? It is different from a Mantainer? There are External Contributors? The role plays an important game here. And an Author or Mantainer is not necessarily an individual, it could be even an Institution or Team. Often Institutions, for example, have hierarchical names, historical names, they are joined or splitted, etc. Modelling this set of interactions in an universal way is very complex [*], and there should be a reasonable stopper, which I honestly think, is the most difficult thing to find because requires a lot of experience building systems. I am the only one who think this? This little issue (not having Authors and friends as objects) prevents doing possibly some pretty cool tools. -What about finding the role of somebody in a method? -And what about assessing the author of a class and the maintainer? -You may want to find the e-mail of somebody (to verify a patch, to ask him something), but is not there. -Avoiding impersonation when commiting in public repositories? -You comment a message, compile the method and...magically you're the new "author". -And could limit the evolution of some research developments like Subjectivity, or reverse engineering tools. But, I'm lying to you if I advocate such simplistic view. There's no such Author, and in history the authors as we know today are just a constructed figure in Literature after the Renaissance. In fact computer practicioners adopted that word, as many others, as a common practice taking words from other fields, but there's a real challenge in determining the very nature of an Author. An anonymous method has a writer, but not an author, and one could think the same about auto-generated code. So an author could be a constructed figure out of the writers, and there are other figures not so visible in a first sight. So having a good reification of a Writer, Author, and its roles, bring new possibilities to Smalltalk/Pharo, because the richer your "human model" and vocabulary, the more you can express and think about the continuous, the problem of interpretation and authority, etc. Cheers HernÃ¡n [*] We are facing this situation in our FRBRoo model currently. 2009/7/22 Alexandre Bergel <alexandre(a)bergel.eu> > > This package, in the last core image is modified but not commited so > > when following the steps > > from the HowToContribute wiki page, in the part of creating a mcz > > package with the change the mcz > > generate will include the other uncommited changes. Should I use a > > changeset instead in order to not > > commit changes that I don't want? > > First, you should update your image. It should be a core. Your change > must be produced for Core. > Then, implement your fixe. If more than one package is touched, then > produce a slice. You should save your fix in PharoInbox using > Monticello. > Last step, make sure your fix load in a fresh and updated core image; > add an issue in the google website; send an email to the mailing list. > > > What is the goal with the Author class? > > A reification of author. Authors should not be strings passed around. > >

July 23, 2009

Re: [Pharo-project] The Pharo Toolset Guide (request)

by Carlos Crosetti

Esteban, try selecting a package and doing "publish" so it goes into your fislesystem, you benefit from saving hierarchies into a single compressed file that you can load later on from the same and other images. Carlos -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Esteban A. Maringolo Enviado el: Miercoles, 22 de Julio de 2009 09:16 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: [Pharo-project] The Pharo Toolset Guide (request) Hi, As I told, I'm new to this squeak/pharo world, particulary in relation with its toolset. I'm developing, and by now I was using fileOut/fileIn to manage, save, version, etc my codebase. I would like to know how to create a Monticello repository to host my projects, how to create a package for them, etc. I know there are many versions around, and don't know which is the one in use in the latest Pharo core. Is there a "terse guide" to get a smalltalker coming from other smalltalk to understand the phylosophy behind the Pharo tools, and how to use them? Besides http://www.wiresong.ca/Monticello/UserManual/, is there any other resource I should be aware to learn the mentioned above? Best regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008 11:07 a.m.

July 23, 2009

[Pharo-project] The Pharo Toolset Guide (request)

by Esteban A. Maringolo

Hi, As I told, I'm new to this squeak/pharo world, particulary in relation with its toolset. I'm developing, and by now I was using fileOut/fileIn to manage, save, version, etc my codebase. I would like to know how to create a Monticello repository to host my projects, how to create a package for them, etc. I know there are many versions around, and don't know which is the one in use in the latest Pharo core. Is there a "terse guide" to get a smalltalker coming from other smalltalk to understand the phylosophy behind the Pharo tools, and how to use them? Besides http://www.wiresong.ca/Monticello/UserManual/, is there any other resource I should be aware to learn the mentioned above? Best regards, Esteban A. Maringolo

July 23, 2009

Re: [Pharo-project] How important is ANSI Smalltalk / speeding up ASCII/Latin1/Unicode I/O

by Igor Stasenko

2009/7/23 Dave Mason <dmason(a)mason-rose.ca>: > I have been wondering about ways to speed up character-set > conversions, and related I/O as mentioned in the recent email about > MultiByteFileStream. Â However this change might break parts of the > ANSI Smalltalk hierarchy - particularly around String. > > So my question is, how important is ANSI compatibility? Â Squeak? GNU > Smalltalk? Â VW? VA? > > On a related question, how common is it to subclass String? Â Would it > be a mess if it were its own little hierarchy of classes? > My opinion, that we should follow the standards as much as possible. This is a good to have a layer , common for all dialects, so developers could port their software on different dialects without much hacking. > ../Dave > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 23, 2009

[Pharo-project] Fwd: [Vm-dev] Fwd: Show stopper network bug on Windows

by Igor Stasenko

All, who interested in this, please continue this topic on VM-dev list. Because Andreas is maintainer of windoze VM, and no one knows better than he is of what is working or not and why. ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/7/23 Subject: Re: [Vm-dev] Fwd: [Pharo-project] Show stopper network bug on Windows To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Igor Stasenko wrote: > > Hello guys, those, who not subscribed to the Pharo list. > > I think you should read this: > Â http://code.google.com/p/pharo/issues/detail?id=961 > > since it seems there are some networking problems with Win32 VM. None of these are Windows VM issues. The problem referred to above is simply that someone was using a year-old 3.10.2 VM and tried to call IPv6 primitives (the debug log shows that clearly). The IPv6 prims are not available in these old VMs. The discussion below is similarly confused. The Windows VM does return fully qualified names if your network environment is set up properly. Usually, the domain name is set by DHCP, but you can set it manually in the advanced network settings (on XP it's under network, properties, TCP/IP, advanced, append dns suffixes; Vista will surely differ). Cheers, Â - Andreas -- Best regards, Igor Stasenko AKA sig.

July 22, 2009

Re: [Pharo-project] Author class

by Miguel CobÃ¡

On Wed, Jul 22, 2009 at 5:20 PM, Miguel CobÃ¡<miguel.coba(a)gmail.com> wrote: > On Wed, Jul 22, 2009 at 4:32 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> >>> Yes but I mean, in a clean core image, on first method save it asks >>> for the initials, >>> this is stored on the initials inst var of the singleton Author. >>> >>> But on the World Menu, the set author name, it stores (in a >>> firstname.lastname format) the >>> value entered in the name inst var >>> >>> So, setting one, doesn't set the other. >>> Also, the messages are different for each one (rightly, because are >>> different things) but I >>> want to know what is the inteded behavior from now on to trying to do >>> the changes. >> >> Yes this is the mess. >> Can you propose a nice solution? > > Ok, this is the proposal. > > The Author class will use only the name inst var and related methods. > The initials related are to be unused and later droped in a subsecuent release. > > All the calls to initials methods will be replaced by names methods. > > The format for the name will be free, and suggested by the prompt message to > > firstname.lastname > > but not enforced. > > It will not allow spaces, just letters and periods in places of spaces e.g. > > Miguel CobÃ¡ -> miguel.coba > John The Hacker -> john.the.hacker > Peter O'Toole -> peter.otoole or maybe peter.o.toole > > This period in place of space can be discussed because monticello > replaces periods for "_". > Maybe 'firstname_lastname' should be suggested in the prompt. > > Every package not in core that use the initial methods should be > allowed to use the deprecated > initials methods but strongly urged to change to the names methods. > > At least in core, the initials should not be used anymore. > > What do you think? > > Miguel CobÃ¡ > > Something easier would be to write the same to initials and name no matter what method was called, this would be less disruptive to the image but it will also have to modify the prompt messages to not mention initials but name in all messages. I, personally, vote for the complete delete of initials code mentioned before. Miguel CobÃ¡ >> >>> Is the user only asked for name (forcing a format like >>> firstname.lastname) and the initials >>> are calculated accordingly? >> >> would be good but some people on ss have funky initials because theirs >> were taken. >> This is why initials does not scale. >> >>> Are the initials doomed to disappear, and the only interface will be >>> the name (and possibly the >>> email and other fields mentioned) to identify a person? This means to >>> modify all the senders to >>> initial methods and point them to name methods. With the time, the >>> initials inst var will be droped >>> from the Author class. >> >> I think so. >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 22, 2009