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

Re: [Pharo-project] Do you want to discuss about papers?

by Mariano Martinez Peck

> > Hi Mariano, > > i like the idea of open research or open science : > http://en.wikipedia.org/wiki/Open_research > Research ideas should be implemented as open-source software, papers > and date should be freely available to everyone. > But i think, you are a bit optimistic about discussing and sharing > about papers before they are submitting. People would like to share > their papers with close friends or colleagues, but i guess they will > not release they paper unfinish in a public mailing-list. > > Ok. Perfect. Yes, I was just being to optimistic :) > In spite of this, i like the idea of sharing research ideas especially > among different communities. For example, i'm looking from interested > people to discuss ideas about using software engineering (especially > dynamic language like Smalltalk) in the context of robotics. I think > there is a lot of mutual interests here. > > I like the idea of a smalltalk-research community because sometimes > you are a bit alone in your laboratory fighting against other people > that are doing Java or other boring stuff. Yes, there is some islands > around the world where several Smalltalkers are together, but these > are exceptions. > So i vote for smalltalk-research ;-) > > Cool :) So....we agree with the name smalltalk-research ? > Best regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 2, 2010

Re: [Pharo-project] How do I actually start seaside using Workspace for Installing external projects?

by Mariano Martinez Peck

On Mon, Feb 1, 2010 at 7:58 PM, Matthias Berth < matthias.berth(a)googlemail.com> wrote: > Hi, > > > It's great to see the welcome workspaces in the most recent pharo 1.0rc2! > > I have executed the loading of ConfigurationOfSeaside28, and now I > want to see my little seaside app. I have followed the seaside book > (made a subclass of WAComponent, registered it). Now I tried to go to > http://localhost:8080/ but I get nothing. Looks like seaside is not > started... > > What can I do? > > What should we write in the welcome workspace to fix this problem for > beginners? > I am not sure. Because then, I also would need to explain how to start Moose, or Aida, or Magma, or whatever. That's where you have a link to the website of the project just in case you need more information. What others think ? It would be cool if each project can have its own welcome workspace. > > What do I have to do to get a change in the text into the next release? > > I will take care. > Cheers > > Matthias > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 2, 2010

Re: [Pharo-project] any chances issue 1788 may be included in 1.0?

by Adrian Lienhard

Yes, if this is important and not a big change we add it to 1.0. I updated issue #1788. Cheers, Adrian On Feb 2, 2010, at 14:20 , Esteban Lorenzano wrote: > Hi, > Is there any changes we can include fix 1788 in 1.0? it is a serious > bug for those of us who uses SMTPClient :( > I can add it my self, but need an authorization :) > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 2, 2010

[Pharo-project] any chances issue 1788 may be included in 1.0?

by Esteban Lorenzano

Hi, Is there any changes we can include fix 1788 in 1.0? it is a serious bug for those of us who uses SMTPClient :( I can add it my self, but need an authorization :) Cheers, Esteban

Feb. 2, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Henrik Johansen

Den 02.02.2010 13:14, skrev Henrik Johansen: > For information: > (1 to: 3) collect: [:h | [CompiledMethod allInstancesDo: [:each | each > getSourceFromFile]] timeToRun] > > Standard way, which both registers in the FileRegistry, and does close > at end of getSourceFromFile: > #(13348 12786 12712) > > Explicit closing with readOnlyFileNamed:do: > #(12091 12061 12189) > Blargh, numbers were without nextChunk update. With latest version, the differences are: Standard way, which both registers in the FileRegistry, and does close at end of getSourceFromFile: #(7697 7684 7694) Explicit closing with readOnlyFileNamed:do: #(6586 6597 6594) Cheers, Henry

Feb. 2, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Henrik Johansen

Den 02.02.2010 13:00, skrev Schwab,Wilhelm K: > Henry, > > I would not toss your first thought too quickly. Staying clear of finalization is a big benefit. I have never been able to trust it (for files) on Dolphin, which has a remarkably better implementation of weak collections and finalization than Squeak/Pharo. > > Bill > Stephane's question was not what it should do differently though, but what it did do differently ;) For information: (1 to: 3) collect: [:h | [CompiledMethod allInstancesDo: [:each | each getSourceFromFile]] timeToRun] Standard way, which both registers in the FileRegistry, and does close at end of getSourceFromFile: #(13348 12786 12712) Explicit closing with readOnlyFileNamed:do: #(12091 12061 12189) Considering the amount of work done in reading each source, that's not entirely insignificant, but it requires quite a large amount of additional private protocol in the FileStream classes... Cheers, Henry

Feb. 2, 2010

[Pharo-project] ScriptManager bugs

by Torsten Bergmann

Hi Mariano, I've fixed: - #perform:orSendTo: problems - the "cancel" dialog behavior (#isEmpty -> #isEmptyOrNil) - text messages - drag and drop of scripts - the code to use theming now (Polymorph) - to use shout workspace (if available) for "tear off" - a crash when you tried to "import" a non existent file - the export to warn if file exists - ... The metacello configuration is updated, just use ConfigurationOfScriptManager in version 1.0. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 2, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Schwab,Wilhelm K

Henry, I would not toss your first thought too quickly. Staying clear of finalization is a big benefit. I have never been able to trust it (for files) on Dolphin, which has a remarkably better implementation of weak collections and finalization than Squeak/Pharo. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Tuesday, February 02, 2010 5:08 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] readOnlyFileNamed:do: vs. ... Scratch that. It's what I would have done with a fileNamed:do: selector :) The main difference is readOnlyFileNamed:do: does not evaluate the block if file creation returns nil, while the second code errors out with stream dnu setConverterFromCode if the file could not be opened for any reason. Cheers, Henry Den 02.02.2010 11:02, skrev Henrik Johansen: > My guess is he uses a method which does not register the file in > FileRegistry, thus avoids a WeakDict cleanup when he closes the file > after the block has been evaluated. > (eg readOnlyFileNamed:do: vs. readOnlyFileNamed:) Thus, a lot of time > is saved from not doing weak registry cleanup. > (Which can be a large chunk of the total time when you do many small > operations). > > Cheers, > Henry > > Den 02.02.2010 10:50, skrev StÃ©phane Ducasse: > >> Nicolas I saw that in squeak you changed and use readOnlyFileNamed:do: >> I like it but I would like to understand what is the key advantage >> >> >> fromFileNamed: aName >> FileStream readOnlyFileNamed: aName do: [:stream | >> stream setConverterForCode. >> self fileInFrom: stream] >> >> fromFileNamed: aName >> | stream | >> stream := FileStream readOnlyFileNamed: aName. >> stream setConverterForCode. >> [self fileInFrom: stream] ensure: [stream close]. >> >> _______________________________________________ >> 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

Feb. 2, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Henrik Johansen

Scratch that. It's what I would have done with a fileNamed:do: selector :) The main difference is readOnlyFileNamed:do: does not evaluate the block if file creation returns nil, while the second code errors out with stream dnu setConverterFromCode if the file could not be opened for any reason. Cheers, Henry Den 02.02.2010 11:02, skrev Henrik Johansen: > My guess is he uses a method which does not register the file in > FileRegistry, thus avoids a WeakDict cleanup when he closes the file > after the block has been evaluated. > (eg readOnlyFileNamed:do: vs. readOnlyFileNamed:) > Thus, a lot of time is saved from not doing weak registry cleanup. > (Which can be a large chunk of the total time when you do many small > operations). > > Cheers, > Henry > > Den 02.02.2010 10:50, skrev StÃ©phane Ducasse: > >> Nicolas I saw that in squeak you changed and use readOnlyFileNamed:do: >> I like it but I would like to understand what is the key advantage >> >> >> fromFileNamed: aName >> FileStream readOnlyFileNamed: aName do: [:stream | >> stream setConverterForCode. >> self fileInFrom: stream] >> >> fromFileNamed: aName >> | stream | >> stream := FileStream readOnlyFileNamed: aName. >> stream setConverterForCode. >> [self fileInFrom: stream] ensure: [stream close]. >> >> _______________________________________________ >> 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 > > >

Feb. 2, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Henrik Johansen

My guess is he uses a method which does not register the file in FileRegistry, thus avoids a WeakDict cleanup when he closes the file after the block has been evaluated. (eg readOnlyFileNamed:do: vs. readOnlyFileNamed:) Thus, a lot of time is saved from not doing weak registry cleanup. (Which can be a large chunk of the total time when you do many small operations). Cheers, Henry Den 02.02.2010 10:50, skrev StÃ©phane Ducasse: > Nicolas I saw that in squeak you changed and use readOnlyFileNamed:do: > I like it but I would like to understand what is the key advantage > > > fromFileNamed: aName > FileStream readOnlyFileNamed: aName do: [:stream | > stream setConverterForCode. > self fileInFrom: stream] > > fromFileNamed: aName > | stream | > stream := FileStream readOnlyFileNamed: aName. > stream setConverterForCode. > [self fileInFrom: stream] ensure: [stream close]. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Feb. 2, 2010