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

Re: [Pharo-project] Issue 2230 in pharo: ArrayedCollection class>>newFromStream:

by pharo＠googlecode.com

Comment #5 on issue 2230 by stephane...(a)gmail.com: ArrayedCollection class>>newFromStream: http://code.google.com/p/pharo/issues/detail?id=2230 Thanks esteban. Indeed we should really check

Feb. 6, 2011

Re: [Pharo-project] Issue 2146 in pharo: Fix SystemChangeNotification for traits.

by pharo＠googlecode.com

Updates: Cc: cy.delaunay Comment #4 on issue 2146 by stephane...(a)gmail.com: Fix SystemChangeNotification for traits. http://code.google.com/p/pharo/issues/detail?id=2146 Cyrille could you check if PackageOrganiser gets notified one trait creation...?

Feb. 6, 2011

Re: [Pharo-project] Issue 3539 in pharo: SettingBrowser class comment is out of date

by pharo＠googlecode.com

Updates: Status: closed Comment #4 on issue 3539 by stephane...(a)gmail.com: SettingBrowser class comment is out of date http://code.google.com/p/pharo/issues/detail?id=3539 (No comment was entered for this change.)

Feb. 6, 2011

Re: [Pharo-project] Issue 3658 in pharo: Dictionaries corrupt when loaded from image segment

by pharo＠googlecode.com

Comment #1 on issue 3658 by stephane...(a)gmail.com: Dictionaries corrupt when loaded from image segment http://code.google.com/p/pharo/issues/detail?id=3658 Adrian this is for 1.1.2, 1.2 and 1.3 ?

Feb. 6, 2011

Re: [Pharo-project] Issue 3654 in pharo: Fixes from Netstyle for 1.1.2

by pharo＠googlecode.com

Updates: Labels: 1.3 Comment #2 on issue 3654 by stephane...(a)gmail.com: Fixes from Netstyle for 1.1.2 http://code.google.com/p/pharo/issues/detail?id=3654 (No comment was entered for this change.)

Feb. 6, 2011

Re: [Pharo-project] [COTDC] 2 - SmalltalkEditingState

by StÃ©phane Ducasse

I will add them now to the classes. No need for a slice. On Feb 6, 2011, at 9:12 AM, laurent laffont wrote: > You win an extra ball. Multiball mode activated :) > > Laurent > > > On Sat, Feb 5, 2011 at 10:28 PM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > yep, me! me!, I want to play :) > > -------------- > The uncommented class selection algorithm should take undocumented parent classes before. Thus, it is difficult to document SmalltalkEditingState before EditingState is itself documented. So, I first give a documentation for EditingState and then a small additional comment for SmalltalkEditingState. > Maybe the comments about editing session is misplaced (better in TextMorph, in TextEditor ?) > > with my bad English: > > EditingState comments: > > I store the current state of an editing session. An instance of mine is shared by all TextEditor instances that are created during an editing session managed by a TextMorph (see below for more explanations about editing session). The state data are basically made of an undo/redo manager and of all data needed in order to manage text editing undo and redo (mainly all informations for the current and previous selection intervals). > I'm created by a TextEditor at the beginning of an editing session (see TextEditor>>editingStateClass and TextEditor>>editingState). Specializations can be introduced to fit a particular TextEditor subclass need. > > Editing session: > An editing session starts when a TextMorph is created (precisely, when a TextEditor instance is first assigned to a TextMorph editor instance variable). An editing session ends when a TextMorph is deleted. During an editing session, a TextMorph can make use of a lot of TextEditor instances, one at a time. As an example, each time a TextMorph is resized, its editor is released and a new one that fit the TextMorph physical properties is created. Another example, when a TextMorph loses the keyboard focus, then its editor could be fully released; it is created again when the TextMorph retrieves the focus. > When an editor is created by a TextMorph, the state of the previous TextEditor, stored in its associated EditingState instance, is got and passed to the newly created editor. Thus the editing session remains stable (see TextEditor >> #stateArray and TextMorph >> #installEditorToReplace:). So TextEditor instances are extremely volatile whereas its associated EditingState instance remains during the whole editing session. > > Instance Variables: > emphasisHere <Array of TextAttribute> > pointBlock <CharacterBlock> > markBlock <CharacterBlock> > startOfTyping <Integer> > previousInterval <Interval> > previousSelection <Text> > undoManager <HistoryIterator> > lastParenLocation <Integer> > mouseDownInterval <Interval> > secondarySelectionToken ** obsolete ** should be removed ** > > - emphasisHere: > The TextAttributes that are used for the newly entered text > > - pointBlock: > The CharacterBlock where a selection begins (where the mouse has first pointed) > > - markBlock: > The CharacterBlock where a selection ends > > - startOfTyping: > The index of the first character which has been entered during the currently undoable/redoable portion of text (see TextEditor>>#openTypeIn and TextEditor>>#doneTyping) > > - previousInterval: > Previous interval used for undo/redo actions > > - previousSelection: > The previously selected text for undo/redo actions > > - undoManager: > The undo/redo manager > > - lastParenLocation: > Keep the position of the open parenthesis which corresponds to the last entered close parenthesis > > - mouseDownInterval: > The position of the first mouse down in the editor > > ----------------------------------- > > SmalltalkEditingState comments: > > See EditingState comments. > SmalltalkEditingState is made to manage data for Smalltalk code editing sessions (such as a selector chooser). > > Instance Variables: > selectorChooser <SelectorChooserMorph> > > - selectorChooser > The basic selector chooser which is popup to fetch available selectors or class names begining with a prefix. The prefix is token from the current caret location (see SelectorChooserMorph comments) > > > > > > Le 05/02/2011 18:08, StÃ©phane Ducasse a Ã©crit : > > I'm the logic behind a texteditor. I'm a kind of strategy object responsible of handling edit operations of an editor such as undo, text emphasis, mouse handle actions. > > > > On Feb 5, 2011, at 5:40 PM, laurent laffont wrote: > > SmalltalkEditingState > > > >

Feb. 6, 2011

Re: [Pharo-project] [COTDC] 2 - SmalltalkEditingState

by laurent laffont

You win an extra ball. Multiball mode activated :) Laurent On Sat, Feb 5, 2011 at 10:28 PM, Alain Plantec <alain.plantec(a)yahoo.com>wrote: > yep, me! me!, I want to play :) > > -------------- > The uncommented class selection algorithm should take undocumented parent > classes before. Thus, it is difficult to document SmalltalkEditingState > before EditingState is itself documented. So, I first give a documentation > for EditingState and then a small additional comment for > SmalltalkEditingState. > Maybe the comments about editing session is misplaced (better in TextMorph, > in TextEditor ?) > > with my bad English: > > EditingState comments: > > I store the current state of an editing session. An instance of mine is > shared by all TextEditor instances that are created during an editing > session managed by a TextMorph (see below for more explanations about > editing session). The state data are basically made of an undo/redo manager > and of all data needed in order to manage text editing undo and redo (mainly > all informations for the current and previous selection intervals). > I'm created by a TextEditor at the beginning of an editing session (see > TextEditor>>editingStateClass and TextEditor>>editingState). Specializations > can be introduced to fit a particular TextEditor subclass need. > > Editing session: > An editing session starts when a TextMorph is created (precisely, when a > TextEditor instance is first assigned to a TextMorph editor instance > variable). An editing session ends when a TextMorph is deleted. During an > editing session, a TextMorph can make use of a lot of TextEditor instances, > one at a time. As an example, each time a TextMorph is resized, its editor > is released and a new one that fit the TextMorph physical properties is > created. Another example, when a TextMorph loses the keyboard focus, then > its editor could be fully released; it is created again when the TextMorph > retrieves the focus. > When an editor is created by a TextMorph, the state of the previous > TextEditor, stored in its associated EditingState instance, is got and > passed to the newly created editor. Thus the editing session remains stable > (see TextEditor >> #stateArray and TextMorph >> #installEditorToReplace:). > So TextEditor instances are extremely volatile whereas its associated > EditingState instance remains during the whole editing session. > > Instance Variables: > emphasisHere <Array of TextAttribute> > pointBlock <CharacterBlock> > markBlock <CharacterBlock> > startOfTyping <Integer> > previousInterval <Interval> > previousSelection <Text> > undoManager <HistoryIterator> > lastParenLocation <Integer> > mouseDownInterval <Interval> > secondarySelectionToken ** obsolete ** should be removed ** > > - emphasisHere: > The TextAttributes that are used for the newly entered text > > - pointBlock: > The CharacterBlock where a selection begins (where the mouse has first > pointed) > > - markBlock: > The CharacterBlock where a selection ends > > - startOfTyping: > The index of the first character which has been entered during the > currently undoable/redoable portion of text (see TextEditor>>#openTypeIn and > TextEditor>>#doneTyping) > > - previousInterval: > Previous interval used for undo/redo actions > > - previousSelection: > The previously selected text for undo/redo actions > > - undoManager: > The undo/redo manager > > - lastParenLocation: > Keep the position of the open parenthesis which corresponds to the last > entered close parenthesis > > - mouseDownInterval: > The position of the first mouse down in the editor > > ----------------------------------- > > SmalltalkEditingState comments: > > See EditingState comments. > SmalltalkEditingState is made to manage data for Smalltalk code editing > sessions (such as a selector chooser). > > Instance Variables: > selectorChooser <SelectorChooserMorph> > > - selectorChooser > The basic selector chooser which is popup to fetch available selectors or > class names begining with a prefix. The prefix is token from the current > caret location (see SelectorChooserMorph comments) > > > > > > Le 05/02/2011 18:08, StÃ©phane Ducasse a Ã©crit : > > I'm the logic behind a texteditor. I'm a kind of strategy object >> responsible of handling edit operations of an editor such as undo, text >> emphasis, mouse handle actions. >> >> >> >> On Feb 5, 2011, at 5:40 PM, laurent laffont wrote: >> >> SmalltalkEditingState >>> >> >> > >

Feb. 6, 2011

Re: [Pharo-project] thinking about a community model of funding

by Dmitri Zagidulin

I agree. Though we absolutely should make the best framework possible, and continue to improve it, the genius of the Smalltalk and Seaside community really lies with what we /do/ with it, the kind of projects we can code. (And the world does not need another Facebook :) I can't believe those guys got that much funding for a replacement. It reminds me of Groupon, which is valuated in more than a billion dollars, has first mover advantage, but there is now more than 12 /funded/ startups that are Groupon clones, that are trying to oust it (and I don't think will be successful)). On Sat, Feb 5, 2011 at 9:22 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > In all of that is a comment that there are already multiple social networking systems available. Â It brings up a few questions, including whether another one is really needed? Â It sounds like a few college kids managed to raise some real money to fund something (aka "buy the beer") that one or two of their peers might do for a senior design project. > > Let's say I read it wrong and there is a big void waiting to be filled. Â It would be interesting to see how Seaside would stack up against the alternatives. Â Interestingly, I was reading on that topic earlier today. > > In my more cynical moments, I think the way for Smalltalkers to succeed is to use it to do things under the radar, leaving the competition wondering what hit them. Â I would not recommend spending time to write a framework or even a turn-key system in the hopes that others will use it. Â If there is a niche that remains to be filled and you want to be the service provider and Seaside is up to the load that you would hope would result from getting it right, then go for it. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Torsten Bergmann [astares(a)gmx.de] > Sent: Saturday, February 05, 2011 5:54 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] thinking about a community model of funding > >>I would like to see a model like that around the pharo virtual machine >emerging >> Â Â Â http://phk.freebsd.dk/VML/ > > Do you know this new funding platform: > > Â Â Â Â Â http://www.kickstarter.com > > There is also an interesting story with that: some guys > announced there they wanted to write a "Facebook" replacement > called "diaspora" that is open and better in privacy things: > > http://www.kickstarter.com/projects/196017994/diaspora-the-personally-contr… > > Interesting enough they got LOTs of money @kickstarter and then they > started coding - in Ruby on Rails. Looks like they got stuck > due to development problems after they released the source code: > > http://mashable.com/2010/09/16/diaspora-source/ > > Maybe they should have used Seaside ... > > Should we spend some spare time to write a Facebook II using > Pharo and Seaside 3.0? Then we would have a killer app and > more people interested ;) > > Bye > T. > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >

Feb. 6, 2011

Re: [Pharo-project] thinking about a community model of funding

by Schwab,Wilhelm K

In all of that is a comment that there are already multiple social networking systems available. It brings up a few questions, including whether another one is really needed? It sounds like a few college kids managed to raise some real money to fund something (aka "buy the beer") that one or two of their peers might do for a senior design project. Let's say I read it wrong and there is a big void waiting to be filled. It would be interesting to see how Seaside would stack up against the alternatives. Interestingly, I was reading on that topic earlier today. In my more cynical moments, I think the way for Smalltalkers to succeed is to use it to do things under the radar, leaving the competition wondering what hit them. I would not recommend spending time to write a framework or even a turn-key system in the hopes that others will use it. If there is a niche that remains to be filled and you want to be the service provider and Seaside is up to the load that you would hope would result from getting it right, then go for it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Torsten Bergmann [astares(a)gmx.de] Sent: Saturday, February 05, 2011 5:54 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] thinking about a community model of funding >I would like to see a model like that around the pharo virtual machine >emerging > http://phk.freebsd.dk/VML/ Do you know this new funding platform: http://www.kickstarter.com There is also an interesting story with that: some guys announced there they wanted to write a "Facebook" replacement called "diaspora" that is open and better in privacy things: http://www.kickstarter.com/projects/196017994/diaspora-the-personally-contr… Interesting enough they got LOTs of money @kickstarter and then they started coding - in Ruby on Rails. Looks like they got stuck due to development problems after they released the source code: http://mashable.com/2010/09/16/diaspora-source/ Maybe they should have used Seaside ... Should we spend some spare time to write a Facebook II using Pharo and Seaside 3.0? Then we would have a killer app and more people interested ;) Bye T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Feb. 6, 2011

Re: [Pharo-project] Build failed in Hudson: Pharo 1.1 #82

by Marcus Denker

On Feb 5, 2011, at 11:08 PM, Lukas Renggli wrote: > On 5 February 2011 17:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> .... Lukas fileserver is not reliably online... so all builds fail. >> >> Sometimes I really do not like distributed versioning systems... > > Something must be wrong with your setup then. Among other things, > distributed versioning systems are designed to handle unreliable > sources nicely. > Hmm... right now it somhoe fails if a repository is offline... https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.1/97/console I am sure the needed mcz files are in the local cache, though. I need to investigate. For caching, I wonder if it would make sense to provide a "global" Monticello cache? So just a amazon S3 with all public mcz files one can possibly be interested in and if MC does not find a file it looks there? Or maybe some form of repository mirrors? Another source for failure is the rb spelling file which I guess I should change to be hosted locally... > > PS: My server is up and running again. I had to shut it down to be > able to finally install some lights in my apartment. Thanks! Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 5, 2011