- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo conf. Social Event

by StÃ©phane Ducasse

Hi, For the conference, the lunches and coffee breaks are covered by INRIA and EMD. Now I would like to organize the social event for the thursday evening. Now our team cannot cover it because our budget is tight but I can have a really good restaurant (I know personally the cook). We could have a really good diner for around 30-35 Euros (with a cook cooking everything live in the back). Now I need to know who would like to join. You can come with your partners. So please let me know because like that I can book the restaurant. Stef

April 23, 2012

Re: [Pharo-project] [ANN] PharoLauncher for Mac users

by Bernhard Pieber

Hi HwaJong Oh, I just watched your demonstration videos and downloaded the PharoLauncher from the App Store. Cool that you put it there! Looks good, I will try it out soon. Cheers, Bernhard Am 23.04.2012 um 17:23 schrieb HwaJong Oh: > If you are a Mac(Lion) user, who program in Pharo or other Squeak-like > Smalltalk (Squeak, Cobalt, Seaside one-click, Croquet, EToy, DrGeo > one-click, ...) , there is a better way to manage your images. > > It is fast to launch an image, easy to manage various VM and image > combinations without confusion, safe to delete image files, fast to > laucn&quit images to review many images, easy to launch many images > simultaneously. > > You can download it in AppStore: > http://itunes.apple.com/us/app/pharo-launcher/id503025789?mt=12 > Demonstration video 1: http://screencast.com/t/jJQD4JjXx > Demonstration video 2: http://screencast.com/t/UZIbf3dk7 > > New version of it is released every one or more weeks. > People who are using PharoLauncher(SeungBum Kim, Kuritar, Serge, Laurent) > gave me many feedbacks, and some of them are implemented. > > I hope you enjoy PharoLauncher. Any feedback is appreciated. > > HwaJong Oh > > > -- > View this message in context: http://forum.world.st/ANN-PharoLauncher-for-Mac-users-tp4580756p4580756.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 23, 2012

Re: [Pharo-project] The video about Athens

by Pavel Krivanek

Hi, on 64bit Fedora with "cairo.i686" installed the right library path is /usr/lib/libcairo.so.2 -- Pavel On Thu, Apr 19, 2012 at 4:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, all > > I recorded a small introductory video about Athens. > Here it is: > > http://vimeo.com/40653315 > > (about 21 minutes). > > I explain some basic stuff like drawing things using Athens canvas, > building paths, use of transformation matrices etc. > > Please note, this is a first video i ever recorded in such context in > my life, so don't be too harsh :) > Also, note that the animations are jagged because of video recording > frame rate, not because it is that slow in reality. > > There are still a blog post pending about it.. which i plan to finish > when i will finish ;) > > -- > Best regards, > Igor Stasenko. >

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Bernhard Pieber

Hi GÃ¶ran, Thanks for your question! I have posted the announcement of the Styled Text Editor to the Pharo list as well because I still have not given up on the idea to port it to Squeak and Pharo. It is not straightforward but I consider it possible. Currently the Styled Text Editor is an external package which is loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis so to port it alone is probably too much effort. What I think can be done is the following: Split Cuis into three parts, a) the parts which are not needed for Styled Text Editor, like the Cuis tools b) the parts of Cuis Morphic the Styled Text Editor depends on â this is in my opinion the most valuable part of Cuis because Juan spent years cleaning it c) the Smalltalk kernel below The idea is to port only part b) and the Styled Text Editor. And it has to be done automatically by a tool which creates packages for Squeak and Pharo, always from the latest code base. In addition you will probably need small Cuis portability packages done manually, one for Squeak and one for Pharo. Being able to always load the latest code base of Styled Text Editor and Cuis Morphic as an external package in Pharo is a prerequisite to look into possibilities of sharing more of the code. I plan to write a more detailed proposal and then to approach ESUG and ask for support for the funding. Any ideas for other sources of funding are highly welcome and could speed things up considerably, of course! ;-) I for one have not given up on the idea that it might be possible to develop substantial components as you called it â thank you for that as well â in a more Squeak-dialect-independent way. ;-) Finally, I would like to take the opportunity and kindly ask everyone who has not done so yet: Please check out Cuis 4.0 and the Styled Text Editor and give us feedback, even if it does not (yet) run on your favourite Squeak dialect! Thank you! Peace, Bernhard P.S. Thanks to GÃ¶ran and Janko for trying to establish different threads for the rather off-topic discussions that my announcement posting has caused. Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: > Hi! > > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: >>> Just cloning it off into Pharo and forking seems... less optimal. Any ideas or thoughts? >> >> I do not get what you mean. I just want to work on our roadmap and make it getting real. >> It is hard enough to get some momentum and to deliver for real. >> So can you help us to get focused? >> People can do what they want. I wrote a vision document. We have a roadmap >> and we will do it. > > Ok, let me clarify. I was just wondering how the Pharo community wants to handle a case where a substantial component (in this case, this new editor) is not *primarily* developed in Pharo (in this case Cuis). > > The simple route is to just copy and fork. But IMHO this doesn't leverage the team already around this editor, right? We (Pharo) can't just go around and forking everything and maintaining everything for ourselves, right? > > I just got interested in that problem - now, later replies indicated that it would still need a substantial rewrite for Pharo, so perhaps the situation I am describing is not really applicable in this case. > > regards, GÃ¶ran >

April 23, 2012

Re: [Pharo-project] ConfigurationOfGrease status?

by StÃ©phane Ducasse

On Apr 23, 2012, at 6:27 PM, Janko MivÅ¡ek wrote: > Thanks Dale, > > What to put in another ConfigurationOf to load just core? (I know I > should RTFM, but your answer will be faster :) loads: #('Core') Stef > > Best regards > Janko > > Dne 23. 04. 2012 18:10, piÅ¡e Dale Henrichs: >> Janko, >> >> If you don't want Slime (the default) loaded, then you should load just the 'Core' group: >> >> (ConfigurationOfGrease project lastVersion) load: 'Core' >> >> This approach holds for all configurations. If the default load does not load what _you_ want, take a look at the configuration and explicitly load the pieces that you do want. In this case the group 'Core' appears to load what you want (at least it excludes SLime). >> >> Dale >> ----- Original Message ----- >> | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Monday, April 23, 2012 4:13:04 AM >> | Subject: [Pharo-project] ConfigurationOfGrease status? >> | >> | Hi guys, >> | >> | I loaded ConfigurationOfGrease on 1.4 : >> | >> | Gofer new >> | squeaksource: 'MetacelloRepository'; >> | package: 'ConfigurationOfGrease'; >> | load. >> | >> | Then (Smalltalk at: #ConfigurationOfGrease) load. returns #load does >> | not >> | understand. If I load: >> | >> | ((Smalltalk at: #ConfigurationOfGrease) project lastVersion) load. >> | >> | then it loads Refactoring browser stuff too. >> | >> | What I expected is to load just base Grease, without tests, and >> | certainly without RB , which in this case could even break something >> | in >> | Pharo tools? >> | >> | So, I propose that someone check and update this configuration to >> | load >> | what most of us expect and with #load class method included. >> | >> | Best regards >> | Janko >> | >> | -- >> | Janko MivÅ¡ek >> | Aida/Web >> | Smalltalk Web Application Server >> | http://www.aidaweb.si >> | >> | >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

April 23, 2012

Re: [Pharo-project] monticello repos speedup

by StÃ©phane Ducasse

April 23, 2012

Re: [Pharo-project] ConfigurationOfGrease status?

by Janko MivÅ¡ek

April 23, 2012

Re: [Pharo-project] monticello repos speedup

by Dale Henrichs

Right now we are having disk io problems with the machine that SS3 is hosted on. In general if the entire db can fit in memory you will get very fast response times once the db grows larger than memory you definitely hit a big speed bump when you have to hit disk ... with that said, the response times on SS3 are not acceptable and we are taking measures to address the problem ... The ss3 data base is larger than the ram we have allocated on the machine ... before adding RAM or tweaking other speedup issues we are endeavoring to address the disk io problem first and while the engineers in our data center are monkeying with that problem, I am not touching anything else. Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, April 23, 2012 8:06:10 AM | Subject: Re: [Pharo-project] monticello repos speedup | | | On 2012-04-23, at 16:56, Sven Van Caekenberghe wrote: | | > Camillo, | > | > On 23 Apr 2012, at 16:26, Camillo Bruni wrote: | > | >> I figured a specific bottleneck of the current implementation of | >> MC is the uniqe version name check. | >> | >> On gemstone this takes 4 seconds! for the pharo inbox, definitely | >> too longâ¦ | > | > That seems like a problem with the SS3 and/or GemStone server. I | > should be much faster: | > | > [ MCHttpRepository new | > parseFileNamesFromStream: (ZnClient new | > beOneShot; | > get: 'http://mc.stfx.eu/ZincHTTPComponents') readStream ] | > timeToRun 227 | > | > (this is for half that many versions, admitted cached in RAM on the | > mc.stfx.eu server) | | well 500ms would be the standard range I expected (as for all | gemstone requests) | - your repos is much faster in that sense | - so will smalltalkhub (from what I saw) | | I filed a bug report on gemstone, see if there can be done anything. | | >> The culprit can be found here | >> | >> MCFileBasedRepository >> includesVersionNamed: aString | >> ^ self allVersionNames includes: aString | >> | >> assuming that the PharoInbox consists of quite some versions | >> (currently 947) this is quite some overhead. | > | > It would be possible to skip the check all together, and fail when | > there is a conflict. | > In a Distributed VCS you can never be sure anyway, right ? | > For me commiting is always slow due to my large package cache. | | as previously discussed yes! the current uniqueness checks are quite | flawed (closed world assumptions / race conditions) | | >> I would suggest the following improvements: | >> | >> - add a specific includesVersionNamed: server-side service | >> - add a simpler allVersionNames service that returns a newline | >> separated list of filenames (not an html doc!) | > | > Could be a solution I guess. | > But checking whether a version exists could be as simple as a HEAD | > request, no ? | | actually true, will try | | > Then we would need almost no extra API, just a minor semantic | > change (with a fallback to a normal real GET). | | true | | > I don't know if the other format would really make much difference, | > but I have to admit it would be more logical. | | all in all the parsing part doesn't use that much time, but still too | much work done for what it is :). | | >> By having specific MC repository implementations everything would | >> be 100% backwards compatible since no services are removed nor is | >> the default http repository implementation changed. | > | > Probably doable. | > | >> what do you think? | > | > BTW, do all repositories (actual, cache, others) have to be checked | > all the time ? | > Can't we at least turn that into an option ? | | if you simply do a HEAD / single request it doesn't really matter | anymore since it's going to be as fast as one single request. I | currently do all checks in parallel so it's only a matter of the | slowest one :) | | |

April 23, 2012

Re: [Pharo-project] ConfigurationOfGrease status?

by Dale Henrichs

Janko, If you don't want Slime (the default) loaded, then you should load just the 'Core' group: (ConfigurationOfGrease project lastVersion) load: 'Core' This approach holds for all configurations. If the default load does not load what _you_ want, take a look at the configuration and explicitly load the pieces that you do want. In this case the group 'Core' appears to load what you want (at least it excludes SLime). Dale ----- Original Message ----- | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, April 23, 2012 4:13:04 AM | Subject: [Pharo-project] ConfigurationOfGrease status? | | Hi guys, | | I loaded ConfigurationOfGrease on 1.4 : | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfGrease'; | load. | | Then (Smalltalk at: #ConfigurationOfGrease) load. returns #load does | not | understand. If I load: | | ((Smalltalk at: #ConfigurationOfGrease) project lastVersion) load. | | then it loads Refactoring browser stuff too. | | What I expected is to load just base Grease, without tests, and | certainly without RB , which in this case could even break something | in | Pharo tools? | | So, I propose that someone check and update this configuration to | load | what most of us expect and with #load class method included. | | Best regards | Janko | | -- | Janko MivÅ¡ek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | |

April 23, 2012

Re: [Pharo-project] The video about Athens

by Igor Stasenko

On 23 April 2012 18:01, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Great work Igor! Â One more step towards nicer looking apps developed > in Pharo in the near future > > What features are missing from a full-blown SVG spec? Gradients? > hehe.. a lot. i now working on more complex document, like the attached.. the bad thing about SVG that most of the stuff are expressed via attributes, while xml structure is fairly simple. and they have a lot of different subtleties and/or defaults for those attributes. -- Best regards, Igor Stasenko.

April 23, 2012