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

Re: [Pharo-project] Just another struggling newbie

by Henrik Johansen

Den 09.12.2010 15:52, skrev Chip Nowacek: > > To the matter: I don't understand why I can't accept a change to my > comment in one of my classes. When I try to accept in the OB Package > Browser, about a dozen calls in, #Utility is being sent #changeStamp > and doesn't understand it. I am in the midst of sorting through the > stack trying to figure out what happened. As you might imagine, it's a > little discouraging for such a basic function to blow up. What makes > it worse, I'm probably the cause of the problem - I just don't know > what I screwed up. I am working in Pharo 1.1.1 and have loaded Magma > and O2 per: > It seems the O2 tools have not been entirely updated to reflect 1.1 "deprecations" (in quotes since they were moved without leaving stubs pointing to their new location). Change Utilities changeStamp to Author changeStamp in the debugger that pops up, and hit proceed :) Cheers, Henry ps. in such cases, the simplest way to find a solution is usually to highlight the message (changeStamp in this instance), then either use alt-m shortcut or right click -> extended search -> implementors of it, and see which one fits what you attempt to do. Alternatively ask on the list if none seem to fit :)

Dec. 9, 2010

Re: [Pharo-project] Just another struggling newbie

by Marcus Denker

On Dec 9, 2010, at 3:53 PM, Chip Nowacek wrote: > Hello everyone, > > While I should have introduced myself before I ran into trouble, it is trouble that has brought me here. I guess I'm glad something provided the excuse to meet you. > > First, a short introduction... > > I'm really new to Smalltalk. Kent Beck said it's a good choice for my project. Technically, I come from the database architecture world - though I am more entrepreneur now than techie. I'm starting up a new company and Kent suggested building a prototype myself instead of bringing someone else in - so here I am. I'm trying to move from Squeak because Pharo feels a little more developer oriented. We'll see how it goes. > > To the matter: I don't understand why I can't accept a change to my comment in one of my classes. When I try to accept in the OB Package Browser, about a dozen calls in, #Utility is being sent #changeStamp and doesn't understand it. I am in the midst of sorting through the stack trying to figure out what happened. As you might imagine, it's a little discouraging for such a basic function to blow up. What makes it worse, I'm probably the cause of the problem - I just don't know what I screwed up. I am working in Pharo 1.1.1 and have loaded Magma and O2 per: > Hello, We did not include O2 in the release precisely because it it not yet mature enough... it has lots of nice features and I understand that people want to use it. But man-power was not there to bring it to a state where all these bugs are fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 9, 2010

[Pharo-project] Issue 3393 in pharo: Better support of configuration dependencies in Monticello Browser

by pharo＠googlecode.com

Status: Accepted Owner: alexandre.bergel CC: da...(a)teleport.com, stephane.ducasse Labels: Difficulty-Easy New issue 3393 by alexandre.bergel: Better support of configuration dependencies in Monticello Browser http://code.google.com/p/pharo/issues/detail?id=3393 Configurations are better handled now. If the configuration you're editing depends on another configuration, then it is correctly defined in the baseline. MonticelloGUI-AlexandreBergel.83 in the inbox

Dec. 9, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost @ Mac OS

by Michael Haupt

Hi Igor, On 9 December 2010 14:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > NBInstaller install. wonderful, thank you *very* much. I installed the examples (which appear to be working) and tests as well, but the tests crash the VM. I have not yet tried to nail the problem down; is this expected behaviour on the Mac? Best, thanks again, Michael

Dec. 9, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Martin Dias

Hi all, Thank you for the discussion, is very interesting for me. Thanks Adrian, I don't have benchmarks with ImageSegment, so I like to see the numbers, how could I reproduce that benchmarks? it would be useful for me. I think that ImageSegment is the best if fits the needs. Maybe if in a future we implement using primitives some things it could be more comparable. As someones said, Fuel is more similar to Parcels, in fact we started working based on this paper: http://scg.unibe.ch/archive/papers/Mira05aParcels.pdf About if "objects are much more times loaded than stored", yes... Fuel is not the universal serialization solution, but I believe it could be useful in some cases. Beside of the speed, I think that is also important the "user experience" part of the purpose ("is worth to spend time while storing in order to have faster loading and user experience"), in the sense of giving more features that makes easier the life of the developer to share their object structures. Maybe Fuel could give more flexibility than ImageSegment to select which objects of the graph store and which not. It could let the user define custom rules. For example if FuelFameExtension is installed, when Fuel stores an object first looks at the Fame metadescription of that object and then only stores the "not derived attributes" of that object. That was necessary to export and import properly Moose models. Martin On Thu, Dec 9, 2010 at 3:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/12/9 Levente Uzonyi <leves(a)elte.hu>: >> On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: >> >>> BTW >>> when giving feedback consider that the guy doing that is spending a lot of >>> time and this will be his master >>> and that the code was not optimize and that there is no dedicated >>> primitive in play. >>> >>> So we will see at the end and I was thinking that our little community >>> would be much more positive but >>> we will continue because we believe that there is some value in that. >> >> Don't get me wrong, I'm not saying that Fuel is not useful. I'm saying that >> improving code loading performance is not that important. >> > > Sort of. > But what is most important, i think that you can exchange objects > between images. > MC really allows you to exchange only with source code, > while with Fuel, i think you could put any object/data into binary > package, and don't bother with > inventing the pervasive ways how to recreate complex (or big) data > structures from array literals :) > > Another interesting aspect of binary format is that you can give > binary to people without > disclosing source code.. (waving to corporate world ;) > >> >> Levente >> >>> >>> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 9, 2010

Re: [Pharo-project] Just another struggling newbie

by Max Leske

Hi Chip. Welcome to the list. In your working directory (the one the image reside in) there should be a file called "SqueakDebug.log" (or Pharo? not sure.) The stacktrace should have been written to that file. Could you copy the trace and post it? Might help in debugging your issue. Cheers, Max On 09.12.2010, at 15:52, Chip Nowacek wrote: > Hello everyone, > > While I should have introduced myself before I ran into trouble, it is trouble that has brought me here. I guess I'm glad something provided the excuse to meet you. > > First, a short introduction... > > I'm really new to Smalltalk. Kent Beck said it's a good choice for my project. Technically, I come from the database architecture world - though I am more entrepreneur now than techie. I'm starting up a new company and Kent suggested building a prototype myself instead of bringing someone else in - so here I am. I'm trying to move from Squeak because Pharo feels a little more developer oriented. We'll see how it goes. > > To the matter: I don't understand why I can't accept a change to my comment in one of my classes. When I try to accept in the OB Package Browser, about a dozen calls in, #Utility is being sent #changeStamp and doesn't understand it. I am in the midst of sorting through the stack trying to figure out what happened. As you might imagine, it's a little discouraging for such a basic function to blow up. What makes it worse, I'm probably the cause of the problem - I just don't know what I screwed up. I am working in Pharo 1.1.1 and have loaded Magma and O2 per: > > DEVImageWorkspaces openExternalProjectWorkspace > > I created a package for my stuff according to that which I have read so far. Maybe I did that correctly. My classes are in a category within that package. > > With introductions complete, I don't intend my future posts to be so long-winded. Thanks for whatever patience you've been able to afford me. > > Chip

Dec. 9, 2010

[Pharo-project] Issue 3392 in pharo: Class finder should probably use a different editor

by pharo＠googlecode.com

Status: Accepted Owner: rydier Labels: Milestone-1.3 New issue 3392 by rydier: Class finder should probably use a different editor http://code.google.com/p/pharo/issues/detail?id=3392 The editor used is a TextEditor, yet the class finder should be smalltalk aware (to f.ex. be able to use OCompletion without having a model accessor) See discussion at http://forum.world.st/Issue-3385-in-pharo-TextEditor-doest-not-understand-m… and the related resolution for 1.2 at http://code.google.com/p/pharo/issues/detail?id=3385

Dec. 9, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Martin Dias

Hi Tudor, Thank you. Yes, just to test the project in a real case, I created a package that uses Fame metadescription like MSE to export and import moose models. In the main page I talk a bit about the extension, but I didn't mentioned it in the summary mail. It needs to be better tested... and a progress bar like MSE! In Moose 4.1: Gofer new squeaksource: 'Fuel'; version: 'Fuel-MartinDias.74'; version: 'FuelFameExtension-MartinDias.10'; load. And opening a new MoosePanel it will have the export to FL and import from FL options. I would like to have your feedback! Martin On Thu, Dec 9, 2010 at 10:02 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Martin, > > Nice project. > > I noticed that you have a package FuelFameExtension. Is this done for the Fame meta engine? If yes, I would be interested in testing it, especially that in the context of Moose we do load the objects significantly more often than we store them :). > > Cheers, > Doru > > > On 8 Dec 2010, at 17:50, Martin Dias wrote: > >> Hi all >> >> Last months I and Tristan have been working on Fuel project, an object >> binary serialization tool. The idea is that objects are much more >> times loaded than stored, therefore it is worth to spend time while >> storing in order to have faster loading and user experience. We >> present an implementation of a pickle format that is based on >> clustering similar objects. >> >> There is a summary of the project below, but more complete information >> is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel >> >> The implementation still needs a lot of work to be really useful, >> optimizations should be done, but we'll be glad to get feedback of the >> community. >> >> >> = Pickle format = >> >> The pickle format and the serialization algorithm main idea, is >> explained in this slides: >> >> http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example >> >> >> = Current features = >> >> - Class shape changing (when a variable has been added, or removed, or >> its index changed) >> - Serialize most of the basic objects. >> - Serialize (almost) any CompiledMethod >> - Detection of global or class variables >> - Support for cyclic object graphs >> - Tests >> >> >> = Next steps = >> >> - Improve version checking. >> - Optimize performance. >> - Serialize more kinds of objects: >> -- Class with its complete description. >> -- Method contexts >> -- Active block closures >> -- Continuation >> - Some improvements for the user: >> -- pre and post actions to be executed. >> -- easily say 'this object is singleton'. >> - Partial loading of a stored graph. >> - Fast statistics/brief info extraction of a stored graph. >> - ConfigurationOfFuel. >> - Be able to deploy materialization behavior only (independent from >> the serialization behavior) >> >> >> = Download = >> >> In a Pharo 1.1 or 1.1.1 evaluate: >> >> Gofer new >> Â Â Â squeaksource: 'Fuel'; >> Â Â Â version: 'Fuel-MartinDias.74'; >> Â Â Â version: 'FuelBenchmarks-MartinDias.4'; >> Â Â Â load. >> >> >> = Benchmarks = >> >> You can run benchmarks executing this line (results in Transcript): >> >> FLBenchmarks newBasic run. >> >> >> Thank you! >> Martin Dias >> > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > >

Dec. 9, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost @ Mac OS

by Igor Stasenko

On 9 December 2010 15:54, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 9 Dec 2010, Igor Stasenko wrote: > >> Hello, >> >> since recently i got access to macs, i were finally able to add NB >> support for Mac OS. >> I built the Cog VM with NativeBoost plugin , which you can download at >> NativeBoost project page [1]. >> >> At image side you just load NativeBoost-Installer package >> and then evaluate: >> >> NBInstaller install. >> >> >> Should i also build Squeak VM with NB plugin, or i could stick with Cog? >> :) > > What about adding NativeBoost to the official VMs? There could be a command > line option to enable/disable it. What do you think? > > i'm not opposed to this. If you remember , i proposed to do this for FFI (keep it as builtin, and enable either via command-line or via .ini file). That is fairly possible. > Levente -- Best regards, Igor Stasenko AKA sig.

Dec. 9, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Igor Stasenko

2010/12/9 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: > >> BTW >> when giving feedback consider that the guy doing that is spending a lot of >> time and this will be his master >> and that the code was not optimize and that there is no dedicated >> primitive in play. >> >> So we will see at the end and I was thinking that our little community >> would be much more positive but >> we will continue because we believe that there is some value in that. > > Don't get me wrong, I'm not saying that Fuel is not useful. I'm saying that > improving code loading performance is not that important. > Sort of. But what is most important, i think that you can exchange objects between images. MC really allows you to exchange only with source code, while with Fuel, i think you could put any object/data into binary package, and don't bother with inventing the pervasive ways how to recreate complex (or big) data structures from array literals :) Another interesting aspect of binary format is that you can give binary to people without disclosing source code.. (waving to corporate world ;) > > Levente > >> >> Stef > -- Best regards, Igor Stasenko AKA sig.

Dec. 9, 2010