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

[Pharo-project] [OT] Phrase about Smalltalk and Ruby

by Mariano Martinez Peck

Hi all. I remember a phrase someone said few months ago and it was something like "I kew Smalltalk was going to reborn, but I didn't know it was going to be called Ruby". Do you remember how exactly the phrase was? do you know the name of the author? thanks Mariano

Nov. 15, 2010

Re: [Pharo-project] permutations / combinations implementation

by Ralph Boland

In Squeak SequenceableCollection>>permutationsDo: will apply a block to each permutation of a collection. I assume it is also in Pharo. I have a package CombinatorialGeneration that implements a number of combinatorial generation algorithms. I use it for generating large numbers of test cases. It's about a man month of work from being ready to release. Then, based on feedback, I will likely have more work to do before it is production ready. It uses some code that as far as I know is not supported in Pharo including the generators code added by Andreas (? Sorry I forget his last name but it is a short name). Hope that helps. Ralph Boland

Nov. 15, 2010

Re: [Pharo-project] permutations / combinations implementation

by Peter Hugosson-Miller

Hi Doru! I did a lot of work with permutations and combinations a few years back when I was writing code to help me solve the challenges in Simon Singh's "The Code Book". It probably isn't comprehensive (and it's all in VisualAge Smalltalk), but I expect it might provide a large chunk of what you're looking for. I could try and find it for you, if you like. -- Cheers, Peter. On 15 nov 2010, at 10:55, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > Is there an implementation of permutations and combinations of a collection? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

Nov. 15, 2010

Re: [Pharo-project] Unix thing? Possible silent failure writing file.

by Schwab,Wilhelm K

You have the impression that I am asking you to do my work. Not the case; I asked you whether a sequence of events was familiar - that's it. The involvement of R and "adding a column" would mean a lot to those who use it. I am not using any of the variations you list below, but I will look at the code behind them; it might offer some clue about any preparation that the newly opened file might need. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Monday, November 15, 2010 8:06 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Unix thing? Possible silent failure writing file. Bill, On 15 Nov 2010, at 13:35, Schwab,Wilhelm K wrote: > Apologies if this comes through as a repeat. > > What is so mysterious/non-responsive about telling you (read the initial email) that I was re-writing an existing file, nothing happened, no errors were reported, and that repeating it with an explicit truncation of the file after opening gave the expected behavior? What others on this list are saying is that you have to provide _Concrete Code Examples_ independent from all decoration (it doesn't matter that you are using R and doing whatever with it). Making a good, short example that others can run will help you and others. You have to make at least the isolation effort first. Even better, you should look as deep into it as you can. Otherwise you will be ignored because you are asking others to do your work. So, you should have written something like (but maybe this is not what you meant or were using/doing): Shouldn't FileStream>>#fileNamed:do: raise an error when overriding ? For example: FileStream fileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'First'; crlf ]. "works" FileStream fileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'Second'; crlf ]. "overwrites - but should fail IMHO" FileStream oldFileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'Third'; crlf ]. "overwrites" FileStream newFileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'Fourth'; crlf ]. "raises error" HTH, Sven PS: And I also think you should make an Google Code Issue when you are sure there is a bug ;-)

Nov. 15, 2010

Re: [Pharo-project] Issue 3264 in pharo: Locale>>#primTimezone fails on Squeak 5

by pharo＠googlecode.com

Comment #1 on issue 3264 by sven.van.caekenberghe: Locale>>#primTimezone fails on Squeak 5 http://code.google.com/p/pharo/issues/detail?id=3264 OK, I hit Return way to fast ;-) So Locale>>#primTimezone always returns 0 on Squeak 5.8b12 on Mac OS X, while it works OK on Cog r2316. This results in things like TimeStamp now always having a zero offset and TimeStamp now asUTC not making a difference. Sven

Nov. 15, 2010

[Pharo-project] Issue 3264 in pharo: Locale>>#primTimezone fails on Squeak 5

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3264 by sven.van.caekenberghe: Locale>>#primTimezone fails on Squeak 5 http://code.google.com/p/pharo/issues/detail?id=3264 We are currently working on version 1.2, so please verify your issue with the latest 1.2 Unstable version before reporting it - we improved a lot the system. If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: Pharo | Pharo-core Pharo core version: <copy from World/System/About> Virtual machine used: <ex: pharo-vm-0.15.2f-linux> Class browser used (if applicable): <ex: O2PackageBrowserAdaptor. If you don't know, print "SystemBrowser default"> Steps to reproduce: 1. 2. 3. Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image):

Nov. 15, 2010

Re: [Pharo-project] Unix thing? Possible silent failure writing file.

by Sven Van Caekenberghe

Bill, On 15 Nov 2010, at 13:35, Schwab,Wilhelm K wrote: > Apologies if this comes through as a repeat. > > What is so mysterious/non-responsive about telling you (read the initial email) that I was re-writing an existing file, nothing happened, no errors were reported, and that repeating it with an explicit truncation of the file after opening gave the expected behavior? What others on this list are saying is that you have to provide _Concrete Code Examples_ independent from all decoration (it doesn't matter that you are using R and doing whatever with it). Making a good, short example that others can run will help you and others. You have to make at least the isolation effort first. Even better, you should look as deep into it as you can. Otherwise you will be ignored because you are asking others to do your work. So, you should have written something like (but maybe this is not what you meant or were using/doing): Shouldn't FileStream>>#fileNamed:do: raise an error when overriding ? For example: FileStream fileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'First'; crlf ]. "works" FileStream fileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'Second'; crlf ]. "overwrites - but should fail IMHO" FileStream oldFileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'Third'; crlf ]. "overwrites" FileStream newFileNamed: '/tmp/foo.txt' do: [ :stream | stream nextPutAll: 'Fourth'; crlf ]. "raises error" HTH, Sven PS: And I also think you should make an Google Code Issue when you are sure there is a bug ;-)

Nov. 15, 2010

Re: [Pharo-project] Unix thing? Possible silent failure writing file.

by Schwab,Wilhelm K

Apologies if this comes through as a repeat. What is so mysterious/non-responsive about telling you (read the initial email) that I was re-writing an existing file, nothing happened, no errors were reported, and that repeating it with an explicit truncation of the file after opening gave the expected behavior? What I find ironic about your objections is that *my* problem is long-since fixed. I was asking a question the answer to which might have shed some light on how to construct an example that would be useful in analyzing what happened. In short, I was trying to help you and others. Sorry, I don't see how giving me "talking Elisa" in response to that is in any way helpful or justified. Examples are good, but the system has to be trustworthy to run in unknown situations. Robust error reporting is critical to that goal. Sadly Squeak has a long tradition of silent failure and a culture that thinks it is perfectly ok. I find it dangerous. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br [csrabak(a)bol.com.br] Sent: Sunday, November 14, 2010 10:44 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Unix thing? Possible silent failure writing file. Wilhelm, This comment, which we know is coming from a SW developer, looks like an automatic "Elisa" like IA bot replying syntactically correct English but not adding exchange in the dialogue. Your description of the unexpected (for you, that is) behavior doesn't allow us to understand minimally if the 'failure' is: a) a mismatch between your expectation and actual, albeit correct behavior; b) an intermittent occurrence or a systematic one, i.e., reproducible one; c) _what_ exactly was you doing in your code and in which context. Also, since you mentioned Windows to Unix transition, is the 'silent' failure in Unix 'not silent' if you run the same code? I hope that by now you can understand why we need a minimum piece of code in order to envision the tackling of an "ultimately fix". Regards, -- Cesar Rabak Em 14/11/2010 19:26, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: If that's how you want it. My concern is not over the failure; it's over its silence. I fear that saying nothing only reduces our collective opportunity to ultimately fix it. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, November 14, 2010 4:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Unix thing? Possible silent failure writing file. send a code snippet else it does not help to send the mail. On Nov 14, 2010, at 10:19 PM, Schwab,Wilhelm K wrote: > Surely I'm not the only person to make the Windows to Unix move. It is either something that happens, or another case of the Squeak primitives failing without saying that they did, let alone why. What you call a crystal ball, I call words from the wise who might have seen something similar before. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br [csrabak(a)bol.com.br] > Sent: Sunday, November 14, 2010 3:43 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unix thing? Possible silent failure writing file. > > Without a minimum snippet of the code that purportedly got into this incident, only a crystal ball can help here. . . > >

Nov. 15, 2010

Re: [Pharo-project] Pharo and Astronomy?

by Enrico Spinielli

Hi Alex, I have some (very immature) code for astronomical algorithms: http://www.squeaksource.com/AdAstra The main implamentation is the VSOP87D. This is tested against the very same data coming from http://cdsarc.u-strasbg.fr/viz-bin/Cat?cat=VI/81 There are utilities classes to compute polinomials (but not sparse ones, given that in astronomical algorithms you do not usually meet them...) and angles... I was not (yet) interested in interfacing with external libraries, but more on the algorithms themselves. Have a look and let me know. BEWARE: code is very IMMATURE. Bye Enrico On Thu, Nov 4, 2010 at 20:14, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi! > > I am looking for any experience in using Pharo to develop software for Astronomy. Especially regarding interoperability with Python, using Mathematical libraries (www.nr.com, www.gnu.org/software/gsl, matplotlib.sourceforge.net/gallery.html) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Enrico Spinielli "Do Androids dream of electric sheep?"â Philip K. Dick "Hear and forget; see and remember;do and understand."âMitchel Resnick

Nov. 15, 2010

Re: [Pharo-project] about OutOfScopeNotification

by StÃ©phane Ducasse

>> > IMO, it should not raise an error, at maximum it should just warn that > global name are shadowed by nested scope. It should compile. > >> | b c | >> b := [ :Object | Object ]. >> c := b value: Object. >> >> is something that I would rather not have compile. Perhaps it should, just as one is free to evaluate >> >> Object := 'this is really a bad idea to evaluate'. >> >> but the latter is at least akin to shooting one's foot with a clearly-marked weapon. Using Object as a temp name is not something that I can ever see as a good idea, but assignments to globals have uses. >> > > The point is, that its not important what name you are using. It is > about a strictness of compiler, and about whether we need > to check for any identifier declared in local scope (such as class > scope, method scope, block scope) clashing with any names defined in > outer scope. > My point that shadowing should be allowed. And we have a Lint there > for pointing out on such clashes. > > It is pointless to enforce strictness, because it works only in one > way: when an outer scope name defined before inner scoped name. > But what if you wrote a method which using some name(s), it compiled > well, and works. But then later you loaded some external package, > which defines a global var with same name. Should your method stop > compiling? I don't think so. +1

Nov. 15, 2010