February 2016 - Pharo-users

Re: [Pharo-users] CDB project

by Pierce Ng

On Fri, Feb 05, 2016 at 01:53:08PM +0100, Nicolas Berveglieri wrote: > we're a group of 4 students learning pharo since a few weeks. We picked up > the CDB project (http://cr.yp.to/cdb.html) to hopefully get it done by > march. If you have any specific request about the project let us now. Cool! I suppose you are going to implement CDB in Pharo that interoperates with djb's C version and not just write an FFI wrapper, yes? Pierce

Feb. 5, 2016

CDB project

by Nicolas Berveglieri

Hello, we're a group of 4 students learning pharo since a few weeks. We picked up the CDB project (http://cr.yp.to/cdb.html) to hopefully get it done by march. If you have any specific request about the project let us now. Oudjail Veis Gamelin Kevin Maroine Maxime Berveglieri Nicolas

Feb. 5, 2016

Re: [Pharo-users] Image Cleaner no longer useful?

by Maximiliano Tabacman

Thanks for the reply Marcus.I just checked, and can confirm that the old process took only 2 minutes and converted aÂ 58,2 MB image (includes Seaside and my web product) into aÂ 26,4 MB production image. By looking at PharoDebug.log, I can tell that this version is: VM: Win32 - IX86 - 6.1 - NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858Image: Pharo5.0 [Latest update: #50491] Hope that helps. This is Pharo 5, so the Image Cleaner must have broken at some point after this version. Let me know if there is any additional information I can provide to help figure it out. On Thursday, February 4, 2016 12:22 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: Hello, Sorry for the late answer. I think there are multiple problemsâ¦ 1) slowness. This is strange that unloading packages is so slow. This looks like a bug to me. 2) image size in Pharo5: We have a bug right now that images *never* shrink. This means that if you savean image once with 80MB, even if the GC cleans up, the saved image stays 80MB. We should fix bothâ¦. On 25 Jan 2016, at 13:32, Maximiliano Tabacman via Pharo-users <pharo-users(a)lists.pharo.org> wrote: From: Maximiliano Tabacman <mtabacman(a)yahoo.com> Subject: Image Cleaner no longer useful? Date: 25 January 2016 at 13:31:28 GMT+1 To: "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org> Reply-To: Maximiliano Tabacman <mtabacman(a)yahoo.com> Hi, and sorry if this has already been discussed. In Pharo 3, I used to be able to do: ImageCleaner cleanUpForProduction and that would correctly remove a lot of unneeded code in the image when preparing for a productive release.Then I would save the cleaned image, and since it had been cleaned, it would be smaller than the original development image (say from 60 mb to 25 mb).This process would take about 2-3 minutes. Then, in Pharo 4 it seems some changes were made here, since the same process took a lot more, like 20 minutes. When I first tried Pharo 5, I was happy to see that it was again down to 2-3 minutes. And here comes my question...Why is it that since some 2 months ago (maybe more), the Pharo 5 images once again require like 20 minutes to complete the cleanUpForProduction process? Also, and this is the most relevant to me, it no longer reduces the image size.So if I want to release a Pharo 5 version based on the latest images, I would be shipping a product that is more than twice the size of previous public versions of my software! Thanks for any insights into this. If it is a known bug, I would like to know if there is any workaround, or alternative objects that I should be using for the process.Also, if it would help for me to run any tests in particular to share and help in fixing this, please let me know.

Feb. 5, 2016

Re: [Pharo-users] Spec doc

by HernÃ¡n Morales Durand

Hi Hilaire, 2016-02-04 13:42 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: > Hello > > I want to evaluate the use of Spec for desktop application. > > What are the recommended spec reading? > > In this case, the best is to read source code in the image. > Is Spec feature complete enough to develop application with complex GUI? > (very subjective question) > > Besides all good intentions and nice innocent feelings, Spec is not ready yet for professional UI development. However you can lower your ambitions by building simpler UI components. The lack of a UI builder is not helping at all. HernÃ¡n

Feb. 5, 2016

Re: [Pharo-users] How to set the server debugger in seaside?

by Johan Brichau

Stef, You know you can contribute and improve it? You should remember a bit more the talk of Kim Mackinnon in Cambridgeâ¦ This negative way of talking about work of others is not the way to get things done. I donât think you would appreciate someone mailing this way about the Pharo interface. In 3.2, the debugger exception handler is the default for development. There is also the programmatic way of changing this: (WAAdmin defaultDispatcher handlerAt: âYourAppâ) exceptionHandler: WADebugErrorHandler cheers Johan > On 04 Feb 2016, at 22:42, stepharo <stepharo(a)free.fr> wrote: > > Thanks this is so inintuitive that I forget 5 min after. > > Le 2/2/16 09:56, Cyril Ferlicot Delbecque a Ã©crit : >> On 02/02/2016 09:47, stepharo wrote: >>> Hi guys >>> >>> I hate so much this bad configuration interface of seaside. >>> I lose all the time 20 min to find how to set the debugger. >>> So I have to do a presentation and I cannot show the debugger. >>> What a great wonderful experience. >>> >>> How can I configure seaside to get the debugger? >>> >>> Stef >>> >> If I remember well on http://localhost:8080/config add a Filter. Then >> click on Â«ConfigureÂ» next to Â«WAExceptionFilterÂ». In Â«Exception HandlerÂ» >> select the debugger. >> > >

Feb. 5, 2016

Re: [Pharo-users] How to set the server debugger in seaside?

by Stephan Eggermont

On 02/02/16 09:47, stepharo wrote: > Hi guys > > I hate so much this bad configuration interface of seaside. > I lose all the time 20 min to find how to set the debugger. > So I have to do a presentation and I cannot show the debugger. > What a great wonderful experience. > > How can I configure seaside to get the debugger? We've added some convenience methods for this, making it easy to deploy both production and development, and making it possible to make the application the default application. QCApplication class>registerAt: anApplicationName ^(WAAdmin register: self asApplicationAt: anApplicationName) preferenceAt: #sessionClass put: self sessionClass; addLibrary: JQDeploymentLibrary; addLibrary: JQUiDeploymentLibrary; yourself QCApplication class>registerForDevelopmentAt: anApplicationName | application | WAAdmin enableDevelopmentTools. application := self registerAt: anApplicationName. application filter configuration at: #exceptionHandler put: WADebugErrorHandler. (self overridesDefaults includes: WAAdmin defaultDispatcher defaultName) ifTrue: [ WAAdmin defaultDispatcher defaultName: anApplicationName ]. ^application QCApplication class>registerForProductionAt: anApplicationName | application | application := self registerAt: anApplicationName. WAAdmin disableDevelopmentTools. WAAdmin defaultDispatcher defaultName: anApplicationName. ^application

Feb. 4, 2016

Re: [Pharo-users] How to set the server debugger in seaside?

by Cyril Ferlicot D.

Le 04/02/2016 22:42, stepharo a Ã©crit : > Thanks this is so inintuitive that I forget 5 min after. > > > If I don't use seaside for more than a week, I need 5-10min to find it. Maybe you can set it at the registry like: MyComponant class>>initialize (WAAdmin register: self asApplicationAt: 'myApp') exceptionHandler: WADebugErrorHandler And remove it for production. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Feb. 4, 2016

Re: [Pharo-users] How to set the server debugger in seaside?

by stepharo

Thanks this is so inintuitive that I forget 5 min after. Le 2/2/16 09:56, Cyril Ferlicot Delbecque a Ã©crit : > On 02/02/2016 09:47, stepharo wrote: >> Hi guys >> >> I hate so much this bad configuration interface of seaside. >> I lose all the time 20 min to find how to set the debugger. >> So I have to do a presentation and I cannot show the debugger. >> What a great wonderful experience. >> >> How can I configure seaside to get the debugger? >> >> Stef >> > If I remember well on http://localhost:8080/config add a Filter. Then > click on Â«ConfigureÂ» next to Â«WAExceptionFilterÂ». In Â«Exception HandlerÂ» > select the debugger. >

Feb. 4, 2016

Pharo mooc registration is available

by stepharo

https://www.france-universite-numerique-mooc.fr/courses/inria/41010/session…

Feb. 4, 2016

Re: [Pharo-users] stupid spur question

by stepharo

Could somene take the time to propose a better class comments? Stef Le 2/2/16 15:11, Werner Kassens a Ã©crit : > Hi Clement, > i see, thanks for this answer. > werner > > On 02/02/2016 03:07 PM, ClÃ©ment Bera wrote: >> Hello, >> >> Both classes (SmallFloat64 and BoxedFloat64) are present on 32 bits and >> 64 bits by default right now. The code base is common between 32 and 64 >> bit images. It is possible to run a 32 bit image without the class >> SmallFloat64, but it is not the default behavior. There are no instances >> of SmallFloat64 in 32 bits and there can't be any. There are details, >> such as the SmallFloat64 class needs to be present to convert a 32 bit >> image to 64 bits with the offline converter and if the code base remains >> common between 32 and 64 bit images, then the specialObjectsArray will >> hold a reference to SmallFloat64 which needs to be updated if one >> removes the SmallFloat64 class. >> >> For servers and desktop application it does not really make sense any >> more to remove these classes in 32 bits as they represent very few kb >> compared to Gb of RAM for laptops and Tb for servers. The Smalltalk >> image is already much smaller than let's say, the JVM default runtime. >> In addition, most computers are 64 bits now so it usually does not make >> sense to release in 32 bits. >> >> On embedded devices, one can consider deploying without classes such as >> SmallFloat64 or LargeInteger to minimize the memory footprint. The >> support for such feature is not very good currently, but it is getting >> slowly better. It could make sense to remove such classes if you are >> targeting a connected object with let's say an ARM Cortex-M4. This is >> part of a larger problem which consists in making the Pharo Kernel >> modular so that we can load only part of it in specific contexts to save >> memory or to reduce the system capabilities. >> >> >> 2016-02-02 14:43 GMT+01:00 Werner Kassens <wkassens(a)libello.com >> <mailto:wkassens@libello.com>>: >> >> On 02/02/2016 02:30 PM, Sven Van Caekenberghe wrote: >> >> Maybe those classes could exist in a 32-bit image as empty >> subclasses of float ? >> >> that is, what i hope <g> >> >> werner >> >> > >

Feb. 4, 2016