- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Creating temporary classes for testing

by Alexandre Bergel

This is something that I often need. I have always addressed this as follows: Added a 'classes' instance variable in my unit test. Added a bunch of methods such as: createClassNamed: aSymbol superclass: aSuperclass instVarNames: instVarNames | cls | cls := aSuperclass subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: '' poolDictionaries: '' category: 'Generated'. self classes add: cls. ^ cls Then in the teardown I have something like: tearDown super tearDown. classes ifNotNil: [:clss | clss do: #removeFromSystem ]. You may also want to remove the empty category in the tearDown. Cheers, Alexandre On 9 Dec 2010, at 14:50, Sean P. DeNigris wrote: > > > Noury Bouraqadi-2 wrote: >> >> -You want to test something related to classes, and in this case you can >> use the SUnit extension I introduced a while ago ClassFactoryForTestCase. >> It's part of the core image. >> > > Cool, that's it exactly. > > Now I have two new questions: > * What if ClassFactoryForTestCase used the separate-SystemDictionary > approach? Wouldn't you only need to clean up the logs and the classes would > get gc-ed (even if cleanup was never called)? > * Is my OP correct that it is safe to do what I was doing i.e. no effect to > the system (except maybe the doit in the changes)? (I may have another > application for it) > > Thanks. > Sean > -- > View this message in context: http://forum.world.st/Creating-temporary-classes-for-testing-tp3080408p3080… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 9, 2010

Re: [Pharo-project] Creating temporary classes for testing

by Sean P. DeNigris

Noury Bouraqadi-2 wrote: > > -You want to test something related to classes, and in this case you can > use the SUnit extension I introduced a while ago ClassFactoryForTestCase. > It's part of the core image. > Cool, that's it exactly. Now I have two new questions: * What if ClassFactoryForTestCase used the separate-SystemDictionary approach? Wouldn't you only need to clean up the logs and the classes would get gc-ed (even if cleanup was never called)? * Is my OP correct that it is safe to do what I was doing i.e. no effect to the system (except maybe the doit in the changes)? (I may have another application for it) Thanks. Sean -- View this message in context: http://forum.world.st/Creating-temporary-classes-for-testing-tp3080408p3080… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2010