- Pharo-dev - lists.pharo.org

[Pharo-project] Progress bar
by StÃ©phane Ducasse Dec. 13, 2011

Dec. 13, 2011

Hi I was looking how we could improve the situation of the progress bar. We could "simply" remove some annoying updates (I did some first analysis because I got tired of this). I will try to continue so that we have less updates all the times. Now what I see is that there is also an architectural problem. I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in different scenarios and depending on the path you want or not to raise feedback. A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be raised or not. Now I have the impression that the architecture should be: - the different part raised events (but this is not clear how) - the top level (the part launching) can absorb and aggregate event to give feedback. I do not know if it makes sense. Do you know how this is done in other systems. Stef

2 4

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo
by Fernando Olivero Dec. 13, 2011

Dec. 13, 2011

Nice! As soon as squeaksource is up, i will import them using the icon importer, so we can give them a try. Fernando On Mon, Dec 12, 2011 at 6:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://www.famfamfam.com/ > ? > > > >> Hi Fernando, >> >> oops... I forgot your icon importer, sorry :P >> >> I would like âfor a futureâ to integrate it to pharo and replace current ThemeIcons with an icon strategy based on your package... maybe that is the best "future scenario" for icons. >> >> best, >> Esteban >> >> El 11/12/2011, a las 8:49a.m., Fernando Olivero escribiÃ³: >> >>> Hi Esteban, nice work! >>> For importing the icons you can use the toolset i've developed: it >>> automates completely the process of importing a complete set of icons >>> of a given family. >>> >>> ExternalIconFamily @ squeaksource. >>> I've used it for importing the Oxygen icon set, and others (you can >>> google the list for previous related emails). >>> >>> Fernando >>> >>> On Sun, Dec 11, 2011 at 10:38 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Esteban >>>> I know that feeling :) >>>> >>>> :) >>>> Now I'm not sure that I would like to carry the Eclipse License around in Pharo :) >>>> What are the other icons sets we could use with a nice license and we do it :). >>>> famfam? >>>> >>>> We should clean also the old icons because some are really old. >>>> Thanks for pushing that. I would love to have new icons for Pharo. >>>> Stef >>>> >>>> >>>> >>>> On Dec 11, 2011, at 3:15 AM, Esteban Lorenzano wrote: >>>> >>>>> Hi, >>>>> >>>>> Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... and I never liked the current Pharo icons, so I took one icon library I really like and changed all needed icons (well... all that I saw). >>>>> Here a couple of screen shots: >>>>> >>>>> <Captura de pantalla 2011-12-10 a la(s) 23.05.55.png> >>>>> <Captura de pantalla 2011-12-10 a la(s) 23.06.20.png> >>>>> >>>>> Of course, I don't think they are perfect (also maybe I didn't pick the best icons), but I think they look a lot better than the older. >>>>> >>>>> If you want to see how they look, this are the packages: >>>>> >>>>> for Pharo 1.3: >>>>> >>>>> <Eclipse-Icons-EstebanLorenzano.2.mcz> >>>>> >>>>> for Pharo 1.4: >>>>> >>>>> <Eclipse-Icons-EstebanLorenzano.4.mcz> >>>>> >>>>> >>>>> Then you execute: >>>>> >>>>> ThemeIcons initializeIcons. >>>>> World resetWorldMenu. >>>>> >>>>> ... and enjoy your new icons :) >>>>> >>>>> btw... this icons are in an open-source license, the EPL: http://www.eclipse.org/legal/epl-v10.html >>>>> so, maybe âif all agreeâ, we can add this icons to regular distribution :) >>>>> >>>>> best, >>>>> Esteban >>>>> >>>> >>>> >>> >> >> >

2 1

Re: [Pharo-project] native boost is the best thing since COGVM
by Fernando Olivero Dec. 13, 2011

Dec. 13, 2011

A taste of what will be available: rendering the same GLabel (the gaucho equivalent to StringMorph), scaling the CairoCanvas. Pesudo Code: "create a label" label := GLabel on : 'hello Pango-Cairo'. "draw it on the canvas" label drawOn: canvas. "scale the canvas" canvas translateBy: aDelta ; scaleBy: aScale. "draw it on the canvas" label drawOn: canvas. "repeat" On Sun, Dec 11, 2011 at 7:43 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > Cooool!!! > > On 12/11/11, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> I was able to create the binding to Pango using NB. >> >> The ultimate goal is to provide a cleaner implementation of "text" widgets. >> >> Thanks Igor ! >> >> Fernando >> > > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires

4 4

[Pharo-project] Sprint friday 16 of december
by StÃ©phane Ducasse Dec. 13, 2011

Dec. 13, 2011

Hi guys we want to code and fix stuff for pharo. We will organize a christmas sprint at Lille. You are welcomed, just let us know if you want to participate. We will start at 9h we will indicate if we do it in our building or the INRIA one. Stef

4 5

[Pharo-project] Big Image Tests
by Sven Van Caekenberghe Dec. 13, 2011

Dec. 13, 2011

Today I tried to find out if it would be possible to allocate a large amount of memory in a VM. I used the official 32-bit VM (http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip) and a Pharo 1.3 (http://gforge.inria.fr/frs/download.php/29273/Pharo-1.3-13315.zip) derived image on Ubuntu 11.04 (x86_64) Amazon AWS EC2 m1.large instance (about 8Gb RAM) and the following bash and Smalltalk scripts: run.sh #!/bin/bash script_home=$(dirname $0) script_home=$(cd $script_home && pwd) image=$script_home/pharo-t3.image script=$script_home/run.st args=$* vm=$script_home/bin/CogVM options="-mmap 1536m -vm-display-null -vm-sound-null" #echo $vm $options $image $script $args $vm $options $image $script $args run.st | args size monolithic object | FileStream stdout wantsLineEndConversion: true. Smalltalk garbageCollect. FileStream stdout nextPutAll: 'Running run.st with args: '; nextPutAll: Smalltalk commandLine arguments printString; cr; nextPutAll: Smalltalk vmStatisticsReportString. args := Smalltalk commandLine arguments. size := args first asInteger. monolithic := (args size > 1 and: [ args second = 'monolithic' ]). monolithic ifTrue: [ object := ByteArray ofSize: size * 1024 * 1024 ] ifFalse: [ object := Array ofSize: size * 1024. 1 to: size * 1024 do: [ :each | object at: each put: (ByteArray ofSize: 1024) ] ]. Smalltalk garbageCollect. FileStream stdout nextPutAll: 'Allocation of a size '; print: object size; space; print: object class; nextPutAll: ' OK'; cr; nextPutAll: Smalltalk vmStatisticsReportString. Smalltalk quitPrimitive. These were the results trying to allocate 1GB: $ ./run.sh 1024 Running run.st with args: #('1024') uptime 0h0m0s memory 49,103,224 bytes old 36,625,732 bytes (74.60000000000001%) young 9,812 bytes (0.0%) used 36,635,544 bytes (74.60000000000001%) free 12,467,680 bytes (25.400000000000002%) GCs 8 (90ms between GCs) full 2 totalling 212ms (29.400000000000002% uptime), avg 106.0ms incr 6 totalling 10ms (1.4000000000000001% uptime), avg 1.7000000000000002ms tenures 0 Allocation of a size 1048576 Array OK uptime 0h0m26s memory -1,007,414,928 bytes old -1,020,337,428 bytes (101.30000000000001%) young 5,888 bytes (0.0%) used -1,020,331,540 bytes (101.30000000000001%) free 12,916,612 bytes (-1.3%) GCs 590 (44ms between GCs) full 62 totalling 14,735ms (56.6% uptime), avg 237.70000000000002ms incr 528 totalling 10,225ms (39.300000000000004% uptime), avg 19.400000000000002ms tenures 519 (avg 1 GCs/tenure) Since last view 582 (44ms between GCs) uptime 25.3s full 60 totalling 14,523ms (57.400000000000006% uptime), avg 242.10000000000002ms incr 522 totalling 10,215ms (40.300000000000004% uptime), avg 19.6ms tenures 519 (avg 1 GCs/tenure) $ ./run.sh 1024 monolithic Running run.st with args: #('1024' 'monolithic') uptime 0h0m0s memory 49,103,216 bytes old 36,627,976 bytes (74.60000000000001%) young 9,844 bytes (0.0%) used 36,637,820 bytes (74.60000000000001%) free 12,465,396 bytes (25.400000000000002%) GCs 8 (46ms between GCs) full 2 totalling 208ms (56.1% uptime), avg 104.0ms incr 6 totalling 10ms (2.7% uptime), avg 1.7000000000000002ms tenures 0 Allocation of a size -1073741824 ByteArray OK uptime 0h0m2s memory -1,020,427,928 bytes old -1,037,112,380 bytes (101.60000000000001%) young 5,952 bytes (0.0%) used -1,037,106,428 bytes (101.60000000000001%) free 16,678,500 bytes (-1.6%) GCs 13 (177ms between GCs) full 4 totalling 725ms (31.5% uptime), avg 181.3ms incr 9 totalling 14ms (0.6000000000000001% uptime), avg 1.6ms tenures 0 Since last view 5 (386ms between GCs) uptime 1.9000000000000001s full 2 totalling 517ms (26.8% uptime), avg 258.5ms incr 3 totalling 4ms (0.2% uptime), avg 1.3ms tenures 0 Basically it seems to work. What I find particulary strange is that #vmStatisticsReportString starts reporting negative sizes, also the size of the 1GB ByteArray is reported as negative. Why ? Tomorrow I might try to find out how much further I can take this ? How close to 4GB ? Anybody else tried this ? Sven

3 3

[Pharo-project] About Deprecated13
by StÃ©phane Ducasse Dec. 13, 2011

Dec. 13, 2011

Hi guys Lukas mentions that MenuIcons is gone without notice in 1.4. This is not really true :) It was in the deprecated13 package. Now this package which contains a lot of old old old code does not really load well in 1.4. I fileouted MenuIcons but this is not really a solution. Now since some parts of the system are really ugly, we cannot really spend time making that deprecated13 is fully working loading, but at least we could make sure that we can load it without problem. But for that it requires effort and probably the results may be a list of empty classes. So does it help you if we have that? So far having MenuIcons is working but this is ad-hoc now an automated solution does not work. Stef

1 0

[Pharo-project] Pharo research page
by Alexandre Bergel Dec. 13, 2011

Dec. 13, 2011

Dear All, As you may know, the page http://www.pharo-project.org/about/research lists the publications related to Pharo. If you have a publication related to Pharo and want to see it listed there, send me the bibitem. Example of bibentries are http://scg.unibe.ch/scgbib?_k=4LCS3SCq&query=pharo+2011&display=bibtex Having a url field in your bibitem will enable people download your paper. 5 publications are listed for 2011. I am sure we have published more than that :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

[Pharo-project] Citezen
by Alexandre Bergel Dec. 13, 2011

Dec. 13, 2011

Hi! Apparently, Citezen does not parse scg.bib (http://scg.unibe.ch/scgbib) The following expression raises an error: CZBibParser parse: (FileStream fileNamed: '/Users/alexandrebergel/Workspace/scgbib/scg.bib') contents Is there something obvious I missed? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 8

Re: [Pharo-project] native boost is the best thing since COGVM
by Fernando Olivero Dec. 13, 2011

Dec. 13, 2011

Done, indeed it's a better design now! I've removed the NBCairo class, reified almost all Cairo objects as a subclass of NBCairoObject. I've also added CairoText, for easier drawing of text using Cairo Toy Text API. (and CairoLineCap, CairoLineJoin ) All the examples work again, also the new ones. As soon as squeaksource is up again i'll commit. Fernando pd: I will apply the same refactoring to NBPango also. I still have to answer your questions regarding the use of Pango. On Mon, Dec 12, 2011 at 6:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 12, 2011, at 5:35 PM, Igor Stasenko wrote: > >> On 12 December 2011 17:16, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> ok, i see your point. I will refactor back to Javier's approach. >>> My rationale was to reify the Cairo library as it is, luckily all the >>> other examples work. >> >> Well, it makes sense to do things like that, when you want a fast and >> dirty working stuff. >> But a good wrapping makes a lot of difference: there is no need to >> indicate that you using a library >> through 'self cairo' everywhere. It is just an indirection without any benefit. >> >> Wrapper classes and their instances should provide a required >> functionality through well defined protocols, and then from user's >> standpoint it is really >> makes no difference who implements them. >> That's why we need Athens. > > Indeed we do want to have cairo dependencies inside our system > just encapsulated in their respective canvases. > > >>> If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost >>> automatically associates the type? Because i've been putting directly >>> "int". Would be nice to have a couple of examples of NB (whenever the >>> time is enough for you guys, i know you are busy) >>> >> >> Yes, but these examples were written specifically to show how to wrap >> a library in object-oriented way Â :) >> Look at pharo by example book [1], there you can find an explanation >> how to use shared pools. >> Of course it is far from complete, but my opinion that your >> refactoring gives a bad example to future developers. >> They should think in terms of objects and place callouts in >> corresponding classes with nicely formed protocol(s). >> >> I am looking forward for you to come, so i can explain things more >> directly and easier :) >> >> [1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Ali… >> >>> thanks for the feedback, >>> Fernando >>> >>> >>> >>> On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> CairoSamplePrograms>>rectangleAndText >>>> does not works, because it uses a following method: >>>> >>>> NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext >>>> Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >>>> Â Â Â Â ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â String aFamily, >>>> >>>> cairo_font_slant_t slant, >>>> >>>> cairo_font_weight_t aWeight) ) >>>> >>>> >>>> and during code generation it barks that it unable to resolve >>>> 'cairo_font_slant_t' Â type. >>>> Because NBCairo class does not includes a corresponding shared pool >>>> (NBCairoTypes). >>>> >>>> Also, Fernando, i don't like that you put everything into a single >>>> class (NBCairo). >>>> This is wrong, not object-oriented. The original organization made by >>>> Javier was much more closer to my tastes. >>>> >>>> This approach to wrapping a library is too mechanical. It is much >>>> better to place calls at proper place(s) in proper classes, >>>> rather than putting everything into a single one. Which means that in >>>> this way you are at least 1 message send farther from >>>> real function call. >>>> But in your case its not even that.. >>>> >>>> NBCairoPattern>>status >>>> Â Â Â Â ^ self cairo patternStatusOf: self >>>> >>>> cairo >>>> Â Â Â Â ^ NBCairo default >>>> >>>> so , it is 2 extra message sends, instead of direct call to foreign function! >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

1 0

Re: [Pharo-project] Company/freelance working with Pharo/Seaside
by Stephan Eggermont Dec. 12, 2011

Dec. 12, 2011

Sven wrote: > Having an active community where many people participate in making Pharo better all the time is the best reference. While that is a necessity, it is only relevant for a certain public (technically advanced, developer oriented, long term view). It is not necessarily something other potential customers value. I'm currently doing a data conversion project. Everything outside a timespan of the next 6 months is simply irrelevant. Startups with a lack of deep technological knowledge also cannot tell the difference between a very large but clueless community and a small, but active and knowledgable. > It is also important that success stories, even small ones, are shared. Very much so. And (also) in a form that less technical people can understand. > But I guess that half the people on these lists are available for remotely delivered services in one form or another ;-) That seems like a correct observation. On the other hand these mailing lists function as a filter and are not a good way to match demand and supply. The problem is in explaining where Pharo/Seaside can provide a good solution in business terms. > Although it is important that the community keeps on growing, we reached critical mass a long time ago, IMHO. For innovators yes. For early adopters, no. They value different things. Stephan

2 1