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

Re: [Pharo-project] System Change Notification Broken

by StÃ©phane Ducasse

> I wanted to draw the attention to > > http://code.google.com/p/pharo/issues/detail?id=3396 > > The system change notification service is kind of critical for everything. > > Any idea why it doesn't work anymore in the latest system? Lukas do you know the latest version in which it worked. I fixed yesterday something in RecentList but it should not be the cause of the problem. I started to work on fixing tests and I noticed that one MC test is not working for marking dirty package. I did not have the time to dive into it. Stef

Dec. 9, 2010

Re: [Pharo-project] Just another struggling newbie

by StÃ©phane Ducasse

Welcome Chip Do not hesitate to ask us for help. Now the state of certain tools is clearly not at the level where we would like them to be (believe me). Stef On Dec 9, 2010, at 3:52 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: > > 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

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by StÃ©phane Ducasse

Hi lukas, sorry for your frustration, that I can easily understand I do not remember. There are some changes that when deprecated get in our way. I still think that we need a refactoring deprecate methods because just doing all of them by hand is not possible. I believe that we need to have the RBEngine all the time available and that the notion of core should vanish but I made no progress on the idea of using metacello to manage pharo-dev in a way that we could refactor all the packages at the same time. Stef > I wonder why the old editor functionality was removed instead of being > deprecated until the next release like this is normally done? > > It is extremely difficult to get any GUI related stuff ported, because > the packages cannot simply be loaded. One has to fix part of the > package in the old image, and part of the package in the new image. > One wrong method, and everything blows up irreversibly. > > I spent the whole afternoon trying to get OB, Shout and eCompletion > working. OB and Shout kind of work (thanks to the preparations in the > PharoTaskForces), but they are still subtly broken. eCompletion is > very hard to get working. The idea of making completion part of the > ToolSet doesn't help at all, the patch now just moved from Morphic to > the StandardToolSet class. > > I am frustrated and give up, I revert back to Pharo 1.1. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 9, 2010

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

by Igor Stasenko

On 9 December 2010 17:04, Michael Haupt <mhaupt(a)gmail.com> wrote: > Hi Igor, > > here are some details. > > On 9 December 2010 16:29, Michael Haupt <mhaupt(a)gmail.com> wrote: >> 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? > > most tests are green, but there are some issues: > > 1. NBUnixHeapManagerTests - 2 errors ("unable to map to virtual memory") yeah, because it is for unix, not mac, but test not aware of it :) Mac memory manager (NBMacExternalHeapManager) works ok, because it is involved in a bootstrapping, and you won't be able to run almost anything without successful bootstrap. I have to disable this test , or better use an appropriate heap manager for testing depending on platform. > 2. NBCallbackTests - assertion failure in NBInterpreterProxy >> #callInterpreter > Yeah, callbacks not ready for Cog. I implemented necessary stuff, but haven't time to test it. So, don't use callbacks. Also, Eliot made something cool with FFI , we yet have to see it, and basicly i think i will wait till release of it, so i can play more nicely with it than now. Also, i haven't time to check all image-side code for compatibility with Mac. I even didn't tried to do any external library call, i just tested that assembler + interpreterProxy calls working ok. Currently the Mac NB code using mostly the linux code, and sure thing it could be different in some places specific to mac. > I installed NB in a clean up-to-date Squeak trunk image and use the > Cog/NB VM from the NB Google code page. > > Best, > > Michael > > -- Best regards, Igor Stasenko AKA sig.

Dec. 9, 2010

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

by StÃ©phane Ducasse

Ok even if I disagree. We could imagine a system where we do not need the compiler to be present to load code. >> 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. > > > Levente > >> >> Stef >>

Dec. 9, 2010

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

by StÃ©phane Ducasse

>> It does! >> It seems that you did not work in VW2.5 and 3.0 and when parcels arrived loading was realllllly a big difference >> I do not see why this would not the same with Fuel. > > No I didn't, but the version number of VW is around 7.x now, so I guess the CPUs and VMs are now several times faster. Does it really matter if it takes 200ms or 20ms to load a package? When I load a package with MC so far I still notice it and I would not even think about it. It should load in a unnoticeable amount of time. Stef

Dec. 9, 2010

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

by StÃ©phane Ducasse

> 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 :). :) We tried to save and load some large moose models to see if it could be used for that :)

Dec. 9, 2010

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

by StÃ©phane Ducasse

sure I understood that like that. I think that the use case for fuel is fast loading like VW parcels. > Hi Martin, >>> >>> I took some application for which we use image segments to test Fuel >>> >>> - With Fuel serializing and writing to disk took 330s. File size is 16.1MB >>> - With image segments saving takes 4s and the file size is 2.4MB >>> >> >> but how are you using ImageSegment? just the primitive? because in order >> to compare it to Fuel, you should write all objects, including >> "outPointers". So you should use #writeForExportOn: or similar... > > yes, this includes outPointers serialized with reference stream and writing to disk. > > Adrian > > BTW, I was just providing the numbers that I gathered when looking at Fuel (to see whether that could be interesting for our use case to replace image segments). This was not to say that Fuel is not on the right way or anything, but I though the numbers would be interesting for Martin because they show a real-world use case with a large number of objects. I know that Fuel is in an early stage of development and it doesn't (yet?) have a primitive/plugin to speed things up. >

Dec. 9, 2010

[Pharo-project] Why was the old Editor Functionality Removed?

by Lukas Renggli

I wonder why the old editor functionality was removed instead of being deprecated until the next release like this is normally done? It is extremely difficult to get any GUI related stuff ported, because the packages cannot simply be loaded. One has to fix part of the package in the old image, and part of the package in the new image. One wrong method, and everything blows up irreversibly. I spent the whole afternoon trying to get OB, Shout and eCompletion working. OB and Shout kind of work (thanks to the preparations in the PharoTaskForces), but they are still subtly broken. eCompletion is very hard to get working. The idea of making completion part of the ToolSet doesn't help at all, the patch now just moved from Morphic to the StandardToolSet class. I am frustrated and give up, I revert back to Pharo 1.1. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by StÃ©phane Ducasse

;) >>> Very cool framework, I like it a lot! I definitely vote to eventually >>> replace HTTPSocket with Zinc HTTP Components. >> >> I would love that. >> We plan to open 1.3 Unstable 1 of january :) >> So if you have code for that let me know :) > > Date today >= (Date year: 2011 month: 1 day: 1) > ifTrue: [ > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-HTTP'; > package: 'Zinc-Tests'; > package: 'Zinc-Patch-HTTPSocket'; > load ]. > > ;-) > > Sven

Dec. 9, 2010