August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FW: [Seaside] Changes file too big

by Marcus Denker

From: Robert Sirois <watchlala(a)hotmail.com> Date: August 19, 2010 3:17:56 PM GMT+02:00 To: <pharo-project(a)lists.gforge.inria.fr> Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Mmk, thank you. Pharo: pharo1.0-10505-rc1dev10.01.2.image VM: Squeak 4.2.2beta1U The log file is attached. On Aug 19, 2010, at 3:09 PM, StÃ©phane Ducasse wrote: > on which os are you? > Normally there is a log file just close to your vm or image. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by Henrik Johansen

On Aug 19, 2010, at 3:09 42PM, GÃ¶ran Krampe wrote: > On 08/19/2010 02:03 PM, Henrik Johansen wrote: >> What would you say the right thing is? > > Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using "asString" would give me a String of size 5. Also, "Character space asString" does NOT give me 'Character space' but actually ' '. Maybe its just me, but I'd rather not have SequenceableCollection >> asString mean "If I contain only elements which may represent characters, return a string containing those, if not, return my printString" > > Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String > regards, GÃ¶ran And it is, using either collection as: String, or String withAll: collection In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question "hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements?" Cheers, Henry

Aug. 19, 2010

Re: [Pharo-project] SocketStream enh

by StÃ©phane Ducasse

Tx I will forward that to squeakers because they may be interested too. On Aug 19, 2010, at 3:04 PM, LUIS E QUIJANO wrote: > Stef, > > I have been testing your SocketStream code. So far so good. > > I noticed that if accidentally a SmallInteger versus a CharacterOrByte parameter is used in the method SocketStream>>upTo:, the environment goes into a degraded state that persists until the original instance of SocketStream gets closed. For example, no more new Socket connects. After closing the original instance of SocketStream, the environment "seems" to be back to "normal". A simple example for reproducing the "bad parameter" situation is below. > > Hope this helps, > > Luis > -=-=- > Luis Quijano > quijano(a)panasoft.com > -=-=- > | hostName portNumber hostIP ss data | > hostName := '10.10.10.100'. > portNumber := 10001. > hostIP := NetNameResolver addressForName: hostName timeout: 20. > ss := SocketStream openConnectionToHost: hostIP port: portNumber. > Transcript > show: '---------- Connecting ----------'; cr; > show: 'hostName = ' , hostName; cr; > show: 'hostIP = ' , hostIP printString; cr; > show: 'portNumber = ' , portNumber printString; > cr. > "data := ss upTo: (Character value: 68)." "Good parameter" > data := ss upTo: 68. "Bad parameter" > Transcript > show: 'Data received: '; > show: data; > cr. > ss close. > Transcript > show: '---------- Connection Closed ----------'; > cr. > data inspect. > ===== > At 11:43 AM 8/8/2010, you wrote: >> Hi lukas and others.... >> >> I will integrate the following SocketStream tests and before I would love to see if this >> does not impact seaside >> >> http://code.google.com/p/pharo/issues/detail?id=2767 >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2010

Re: [Pharo-project] FW: [Seaside] Changes file too big

by Mariano Martinez Peck

On Thu, Aug 19, 2010 at 3:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > on which os are you? > Normally there is a log file just close to your vm or image. > > It is in the same directory where your image is and it is called PharoDebug.log but it is opened as append...thus all erros go there. To report an issue is better to remove it, reproduce again the bug and then you will have a clean PharoDebug.log with only that error. cheers mariano > > On Aug 19, 2010, at 3:03 PM, Robert Sirois wrote: > > > How do I get the log? > > > > RS > > > > Date: Wed, 18 Aug 2010 23:00:40 +0200 > > From: marianopeck(a)gmail.com > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big > > > > With condenseCHanges we used to have the problem with "Invalid UTF input > dected" (or something like that), but I don't know a possition error. > Provide, VM and image version, and a clean PharoDebug.log. > > > > cheers > > > > mariano > > > > On Wed, Aug 18, 2010 at 10:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Oops. > > Robert can you tell us which version you are using? > > > > Stef > > > > > How do I clear my changes file? Smalltalk condenseChanges. just brings > up a PositionalStream error. > > > > > > Thanks, RS > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ Pharo-project mailing > list Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by StÃ©phane Ducasse

did you check the senders of asString? Because I would like to assess the cost of changing asString from its printString semantics. Stef On Aug 19, 2010, at 3:09 PM, GÃ¶ran Krampe wrote: > On 08/19/2010 02:03 PM, Henrik Johansen wrote: >> What would you say the right thing is? > > Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using "asString" would give me a String of size 5. Also, "Character space asString" does NOT give me 'Character space' but actually ' '. > > Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String, and not a "printString" so to speak. > > regards, GÃ¶ran > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2010

[Pharo-project] Questions about SRP

by Mariano Martinez Peck

Hi folks/Paul. First, sorry for the cross-posting. Let me know if I should ask this in another place. I am interested in SRP and to understand the differences with SmartRefStream, ImageSegment, SIXX, parcels, etc. First I would like to find as much info as possible. Right now I found: http://techsupport.gemstone.com/entries/175881-srp-3-1-007-0 http://sourceforge.net/projects/srp/ http://map.squeak.org/accountbyid/94ec671f-6615-4ece-9ab0-5d4addc3be8d/pack… These seems to be dead: http://www.ccse.kfupm.edu.sa/~sohel/IMPP/references/About+State+Replication… http://www.whysmalltalk.com/Smalltalk_Solutions/sts2004/pdf/Baumann.pdf And....class side methods #documentation is there something else? Now, my questions: 1) Does SRP supports cycles in my subgraph? If true, how do you achieve that? 2) What happens with objects like nil, true, false, or any other object that has to be unique in Smalltalk. I mean, how can I make sure that when I load the subgraph in another image, I won't have duplicates of nil, true, etc ? 3) Does it provide a way to fix problems like having to rehash Set instances or things like that? 4) Does it supports class reshape? suppose I put in the file objects of a certain class and then I load the file in another image where that class has different shape (re-order of instVar, rename, new insVar, etc...). If true, how do you achieve that? 5) Do you handle BlockClosure (or BlockCOntext), MethodCoontext, CompiledMethods and things like that ? Thanks a lot for any hints you can give me. Mariano

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by GÃ¶ran Krampe

On 08/19/2010 02:03 PM, Henrik Johansen wrote: > What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using "asString" would give me a String of size 5. Also, "Character space asString" does NOT give me 'Character space' but actually ' '. Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String, and not a "printString" so to speak. regards, GÃ¶ran

Aug. 19, 2010

Re: [Pharo-project] FW: [Seaside] Changes file too big

by StÃ©phane Ducasse

on which os are you? Normally there is a log file just close to your vm or image. On Aug 19, 2010, at 3:03 PM, Robert Sirois wrote: > How do I get the log? > > RS > > Date: Wed, 18 Aug 2010 23:00:40 +0200 > From: marianopeck(a)gmail.com > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big > > With condenseCHanges we used to have the problem with "Invalid UTF input dected" (or something like that), but I don't know a possition error. Provide, VM and image version, and a clean PharoDebug.log. > > cheers > > mariano > > On Wed, Aug 18, 2010 at 10:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Oops. > Robert can you tell us which version you are using? > > Stef > > > How do I clear my changes file? Smalltalk condenseChanges. just brings up a PositionalStream error. > > > > Thanks, RS > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2010

Re: [Pharo-project] Senders of #haltOnce

by Guillermo Polito

A time ago I noticed them. And I realized most of them were used to notify error conditions instead of using just #error:. Each halt must be analyzed independently :/ On Thu, Aug 19, 2010 at 9:02 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I > was using this functionality to debug my own code. I submitted a fix: > > Â http://code.google.com/p/pharo/issues/detail?id=2833 > > Also I discovered countless senders of #halt and friends in library > code and tests. This is really bad for continuous integration and for > deploying images, because they open debuggers. All these senders > should be changed to throw an error or fail the test in some > controllable fashion. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 19, 2010

Re: [Pharo-project] Senders of #haltOnce

by StÃ©phane Ducasse

good! Stef On Aug 19, 2010, at 2:02 PM, Lukas Renggli wrote: > I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I > was using this functionality to debug my own code. I submitted a fix: > > http://code.google.com/p/pharo/issues/detail?id=2833 > > Also I discovered countless senders of #halt and friends in library > code and tests. This is really bad for continuous integration and for > deploying images, because they open debuggers. All these senders > should be changed to throw an error or fail the test in some > controllable fashion. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2010