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

Re: [Pharo-project] [on] why can't I write on a WriteStream on an OrderedCollection?

by Nicolas Cellier

While I believe Nile is certainly a valuable work, it is very easy to patch old stream for this particular bug in the interim. http://bugs.squeak.org/view.php?id=2390 http://bugs.squeak.org/view.php?id=7269 http://bugs.squeak.org/view.php?id=7296 Nicolas 2009/4/12 Damien Cassou <damien.cassou(a)gmail.com>: > On Sat, Apr 11, 2009 at 7:39 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: >> Can anyone explain to me why this works fine: >> >> ((WriteStream on: (Array new)) nextPut: #foo) contents. >> >> but this doesn't? >> >> ((WriteStream on: (OrderedCollection new)) nextPut: #foo) contents. > > You should have listened when I presented Nile at ESUG some years ago :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2009

Re: [Pharo-project] [on] why can't I write on a WriteStream on an OrderedCollection?

by Damien Cassou

On Sat, Apr 11, 2009 at 7:39 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > Can anyone explain to me why this works fine: > > ((WriteStream on: (Array new)) nextPut: #foo) contents. > > but this doesn't? > > ((WriteStream on: (OrderedCollection new)) nextPut: #foo) contents. You should have listened when I presented Nile at ESUG some years ago :-) -- Damien Cassou http://damiencassou.seasidehosting.st

April 12, 2009

Re: [Pharo-project] Closure compiler

by Andreas Wacknitz

What about a simple (Squeak Smalltalk) compiler version 2 or compiler 2009? Some time in the future even this "new compiler" will probably an "old compiler" if Squeak survives long enough. Andreas Am 12.04.2009 um 10:50 schrieb StÃ©phane Ducasse: > OK > context taken into account. > > Suggestion > > Pluggable Compiler > Layered Compiler > > OpCode: the Smalltalk Open Compiler > > :) > > Stef > > On Apr 12, 2009, at 12:30 AM, Michael van der Gulik wrote: > >> On 4/12/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Oh yes it was appropriate I did not like simply the fact that you >>> could imply >>> that new compiler would be better named HannanCompiler since >>> people could understand that we were stealing things by not >>> mentioning >>> his name. >>> Now of course you may not have implied that and you may not like my >>> comment. >>> Still my point is clear. I'm greatfull to marcus to have resurrected >>> and maintained >>> this software over the years. >> >> I certainly didn't mean any disrespect or lack of admiration for what >> Marcus has done. It was just a name to avoid ambiguity. >> >> Do you have another suggestion for a name? >> >> Gulik. >> >> -- >> http://gulik.pbwiki.com/ >> >> _______________________________________________ >> 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

April 12, 2009

Re: [Pharo-project] Closure compiler

by StÃ©phane Ducasse

OK context taken into account. Suggestion Pluggable Compiler Layered Compiler OpCode: the Smalltalk Open Compiler :) Stef On Apr 12, 2009, at 12:30 AM, Michael van der Gulik wrote: > On 4/12/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Oh yes it was appropriate I did not like simply the fact that you >> could imply >> that new compiler would be better named HannanCompiler since >> people could understand that we were stealing things by not >> mentioning >> his name. >> Now of course you may not have implied that and you may not like my >> comment. >> Still my point is clear. I'm greatfull to marcus to have resurrected >> and maintained >> this software over the years. > > I certainly didn't mean any disrespect or lack of admiration for what > Marcus has done. It was just a name to avoid ambiguity. > > Do you have another suggestion for a name? > > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2009

[Pharo-project] Integer>> numberOfDigits

by StÃ©phane Ducasse

may be there is a better solution.. Nicolas??

April 12, 2009

Re: [Pharo-project] Help fixing tests

by John M McIntosh

On 11-Apr-09, at 5:11 PM, Mariano Martinez Peck wrote: > Also there can be issues if things like File Handles are over- > allocated and you then rely on finalization to > fix things, which could interfere with things er it's hard to > explain, but once you see it, you know. > Technically this should not be a problem but as you see well something > is funky. I should clarify this, http://bugs.squeak.org/view.php?id=6434 But I see it's STILL an open issue in Pharo, not fixed in pharo0.1-10268dev09.04.1 http://code.google.com/p/pharo/issues/detail?id=517&q=6434&colspec=ID%20Typ… Ok, well let me ASSUME then the odd behavior you see is the result of this bug. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 12, 2009

Re: [Pharo-project] Help fixing tests

by Mariano Martinez Peck

On Fri, Apr 10, 2009 at 11:44 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > In my past dealings with insanity like this is that Sunits for a test > case run technically in no particular order. > However if you have cases where a test case A alters things for B, > then you get failure if B runs before A. > The order is dependent on how the set is created. > > Also there can be issues if things like File Handles are over- > allocated and you then rely on finalization to > fix things, which could interfere with things er it's hard to > explain, but once you see it, you know. > Technically this should not be a problem but as you see well something > is funky. > > What I'd suggest is print the context at the point of error in the > SUnit error handler so you can get some understanding of the failure > case. > > Smalltalk logError:'Fatal error: Sunit Fialed' inContext: thisContext > to: 'SqueakDebugXXXX.log'. Thanks for the advice John. Very useful, not only for this case. I will try it. Thanks! > > I also altered errorReportOn: to slop more data out, in Tweak based > system it's not uncommon to have stack nesting of > 100 methods. > Never can have enough debug data at hand. > > Contextpart>>errorReportOn: strm > "Write a detailed error report on the stack (above me) on a stream. > For both the error file, and emailing a bug report. Suppress any > errors while getting printStrings. Limit the length." > > | cnt aContext startPos | > strm print: Date today; space; print: Time now; cr. > strm cr. > strm nextPutAll: 'VM: '; > nextPutAll: SmalltalkImage current platformName asString; > nextPutAll: ' - '; > nextPutAll: SmalltalkImage current platformSubtype asString; > nextPutAll: ' - '; > nextPutAll: SmalltalkImage current osVersion asString; > nextPutAll: ' - '; > nextPutAll: SmalltalkImage current vmVersion asString; > cr. > strm nextPutAll: 'Image: '; > nextPutAll: SystemVersion current version asString; > nextPutAll: ' ['; > nextPutAll: SmalltalkImage current lastUpdateString > asString; > nextPutAll: ']'; > cr. > strm cr. > SecurityManager default printStateOn: strm. > > "Note: The following is an open-coded version of > ContextPart>>stackOfSize: since this method may be called during a low > space condition and we might run out of space for allocating the full > stack." > cnt := 0. startPos := strm position. > aContext := self. > [aContext notNil and: [(cnt := cnt + 1) < 40]] whileTrue: > [aContext printDetails: strm. "variable values" > strm cr. > aContext := aContext sender]. > > strm cr; nextPutAll: '--- The full stack ---'; cr. > aContext := self. > cnt := 0. > [aContext == nil] whileFalse: > [cnt := cnt + 1. > cnt = 40 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - > - - - - > - - - - - - - - - - - - - - - - -'; cr]. > strm print: aContext; cr. "just class>>selector" > > strm position > (startPos+150000) ifTrue: [strm nextPutAll: > '...etc...'. > ^ self]. "exit early" > cnt > 200 ifTrue: [strm nextPutAll: '-- and more not shown > --'. ^ > self]. > aContext := aContext sender]. > > > > On 10-Apr-09, at 5:19 PM, Mariano Martinez Peck wrote: > > > In Pharo core, it is sometimes green and sometime yellow > > > > I put some flags and see this: > > > \\ > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2009

Re: [Pharo-project] Closure compiler

by Michael van der Gulik

On 4/12/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Oh yes it was appropriate I did not like simply the fact that you > could imply > that new compiler would be better named HannanCompiler since > people could understand that we were stealing things by not mentioning > his name. > Now of course you may not have implied that and you may not like my > comment. > Still my point is clear. I'm greatfull to marcus to have resurrected > and maintained > this software over the years. I certainly didn't mean any disrespect or lack of admiration for what Marcus has done. It was just a name to avoid ambiguity. Do you have another suggestion for a name? Gulik. -- http://gulik.pbwiki.com/

April 11, 2009

Re: [Pharo-project] SUnit GUI

by Oscar Nierstrasz

Wow. I naively assumed that the entire run-time context was still there as long as the red/yellow test was not garbage collected. Rerunning is obviously the smart thing to do, but snafus non-deterministic tests. So you should just click on those yellow tests over and over till the debugger pops up? ;-) - on On Apr 11, 2009, at 23:15, Lukas Renggli wrote: >> indeed but when this is yellow we should be able to click on it? > > Clicking on a yellow or red test just re-runs that test. If the test > then suddenly passes, you are out of luck. > > The problem could be solved by capturing and storing a continuation > when a test fails. Like this a debugger could be opened on the > original stack that caused the error. This however would require a > major rewrite of SUnit, as extra care has to be take when and how to > release resources. > > Lukas > > -- > Lukas Renggli > http://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

April 11, 2009

Re: [Pharo-project] SUnit GUI

by Lukas Renggli

> indeed but when this is yellow we should be able to click on it? Clicking on a yellow or red test just re-runs that test. If the test then suddenly passes, you are out of luck. The problem could be solved by capturing and storing a continuation when a test fails. Like this a debugger could be opened on the original stack that caused the error. This however would require a major rewrite of SUnit, as extra care has to be take when and how to release resources. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 11, 2009