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

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

by Torsten Bergmann

>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. 5, 2011

Re: [Pharo-project] [Pharo-users] [ANN] JNIPort 2.0 for VisualWorks, Pharo and Squeak

by Luc Fabresse

Hi Joachim, JNIPort sounds really great and I will test it. It is really great to have these kind of bindings. For your Alien problem on Cog, I also experienced some troubles with the library path. So I am pretty sure that the problem is on the Cog side. Perhaps the Alien plugin compiled in Cog. I would like to do more investigations on that. #Luc 2011/2/5 Joachim Geidel <joachim.geidel(a)onlinehome.de> > Am 05.02.11 18:11 schrieb Tudor Girba: > > What are the impediments of getting it to work with Cog on Pharo? > > JNIPort relies on Alien, and I have not yet found a Cog VM working with > Alien and JNIPort. > > I tried Squeak 5.8b12 for Mac OS X which identifies itself as Cog, but it > crashes when you just evaluate "LibCLibrary uniqueInstance". Apparently > this > VM version doesn't work with Alien. > > Eliot's latest Cog build for Mac OS X at > http://www.mirandabanda.org/files/Cog/VM/VM.r2349/ is able to load libc. > When I try to use JNIPort, it can't find the library libjvm.dylib when I > create a symbolic link to it in the working directory. When I create a > symbolic link in the subdirectory Cog.app/Contents/Resources, it is able to > load the library, but the VM crashes with a bus error when I try to call > the > first function of the library. I currently have no idea what causes the > error. As the same code runs without problems on a Squeak VM, I don't think > that the problem is in the JNIPort code, but I may be wrong. > > So, no JNIPort on Cog for now. This may change soon, of course. > > Regards, > Joachim Geidel > > > >

Feb. 5, 2011

Re: [Pharo-project] A new GUI visual designer

by nullPointer

Wahooo!!, I didnÂ´t see that screencast: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/raw-… Really spectacular :)) -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3262406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 5, 2011

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

by Lukas Renggli

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. Lukas 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. -- Lukas Renggli www.lukas-renggli.ch

Feb. 5, 2011

Re: [Pharo-project] Issue 1360 in pharo: Add Alien in 1.2

by pharo＠googlecode.com

Comment #20 on issue 1360 by Torsten....(a)astares.de: Add Alien in 1.2 http://code.google.com/p/pharo/issues/detail?id=1360 We should check the state of Alien in newer Win32 VMs, especially after Joachim released JNIPort 2.0 now with Pharo and Squeak support. I asked him offlist about the VM support (IAB32.dll) - he still uses the VM from this issue tracker provided by Marco in squeakVMWithAlien.zip. But this is a 3.11.4.0 Squeak VM and we have newer ones meanwhile.

Feb. 5, 2011

[Pharo-project] Where is OB Was: [what do we do for OmniBrowser?]

by Torsten Bergmann

Guillermo Polito wrote: >(ConfigurationOfOmniBrowser project version: '1.2.4') load > >Downloads OB from PharoOB ;). This is now in "ConfigurationOfPharo-tbn.133", I tried a manual build - it works. So this will come with the next build in the ci.pharo-project.org Side note: I've put a copy of ConfigurationOfOmniBrowser-GuillermoPolito.97.mcz into squeaksource/MetacelloRepository to avoid a new baseline/version with the new config location in ConfigurationOfPharo. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Feb. 5, 2011

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

by Alain Plantec

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. 5, 2011

Re: [Pharo-project] Issue 3660 in pharo: Revert incorrect Monticello branch naming support

by pharo＠googlecode.com

Comment #2 on issue 3660 by stephane...(a)gmail.com: Revert incorrect Monticello branch naming support http://code.google.com/p/pharo/issues/detail?id=3660 yes. Let us know how we can proceed in a coordinated fashion. After that we should really fix mc tool to get the right format. Then do we retrofit this fix to 1.2? 1.1? RIght now I have no idea about the impact.

Feb. 5, 2011

Re: [Pharo-project] Primitive calls in one package

by Schwab,Wilhelm K

If there is a problem finding primitives, then that probably deserves attention in the browsers. Given that collections, sockets, streams, etc. all use primitives, will likely continue to do so, and will also find competition (Nile, new sockets package, etc.), I think it would be inappropriate to set up a presumption that all primitives lurk in one package. It cannot (or should not) be enforced, and would interfere with evolution. With respect, -1. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Laval Jannik [jannik.laval(a)inria.fr] Sent: Saturday, February 05, 2011 3:06 PM To: Pharo Development Subject: [Pharo-project] Primitive calls in one package Hi, What is your opinion about having all primitive calls in one package ? It would be easier to maintain and to find them. Another question: why all existing primitive in VM have not a method in the image ? Cheers, --- Jannik Laval

Feb. 5, 2011

Re: [Pharo-project] Smalltalk for engineers

by Schwab,Wilhelm K

Fair enough. One of my big messages to newbies is that we Smalltalkers refer to "the development tools" with no small measure of reverence, but they look austere to those from the outside. The reason is simple: the Smalltalk tools do not need to have countless toolbars; one can simply interact directly with the objects using the compiler which "lurks just below" the workspaces in the various tools. Welcome aboard! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Geoffroy Couprie [geo.couprie(a)gmail.com] Sent: Saturday, February 05, 2011 1:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Smalltalk for engineers That's what I was trying to express: when you already program with another language, you can easily understand a new language, but you have big assumptions that will slow you down. I just pointed out the most important parts that surprised me when I learned Smalltalk. On Sat, Feb 5, 2011 at 7:28 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > That comment requires elaboration or at least some examples of what one can/should do, but getting past that is a big hurdle in learning Smalltalk. Things old to us can be earth shattering: something as simple as creating a new package (or even just a new class or a new class method somewhere, etc.) vs. writing a whole new program in some other language. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John McIntosh [johnmci(a)smalltalkconsulting.com] > Sent: Saturday, February 05, 2011 5:33 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Smalltalk for engineers > > Casual mention of iPhone port, always helpfull > > On 2/4/11, Geert Claes <geert.wl.claes(a)gmail.com> wrote: >> >> James Robertson spotted this post: >> >> http://unhandledexpression.com/2011/02/04/smalltalk-for-engineers/ >> >> I was especially interested in the statement "you donât understand what you >> can/should do ..." >> -- >> View this message in context: >> http://forum.world.st/Smalltalk-for-engineers-tp3261551p3261551.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > >

Feb. 5, 2011