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

Re: [Pharo-project] Cleaning up SmartRefStream use

by Schwab,Wilhelm K

When I last looked at SmartReferenceStream, it did two things that were bad: (1) it essentially assumed all "users" are in fact programmers, have access to the debugger, and (more presumptuous) know what to to with same. There are times when yelling "it's broken" is about all the system should dare do. SRS made no such distinction. Again, the age of the code is showing. We have exception handling now, and should design with it in mind. (2) reshape code was placed in SRS itself, not in the class that is changing shape. The thing that is being deserialized (which is when problems become apparent) should be in charge of the change. It simplifies both packaging (fewer loose methods to consider, and reduced opportunity for name collisions) and it also helps with using proxies for special circumstances. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Sunday, December 11, 2011 10:54 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cleaning up SmartRefStream use On Sun, Dec 11, 2011 at 4:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: On Dec 11, 2011, at 4:26 PM, Mariano Martinez Peck wrote: > > > On Sun, Dec 11, 2011 at 11:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > Indeed this is fun I was doing the same :) > Now I do not understand why some parts of the system uses dataStream, others ReferenceStream and finally others SmartRefStream > why not all of them use SmartRefStream. > > It is not that I like these guys, but their class comments are pretty clear: > - DataStream does NOT handle cycles, but hence it may be faster in certain scenarios. I guess that for example, Monticello is sure that in its definitions, there cannot be cycles. In addition, it doesn't take into account variables names/order and hence class reshape isn't supported. > - ReferenceStream supports cycles but still doesn't support class reshape. > - SmartRefStream supports cycles and class reshape. > sounds good Yes it does. In fact, I would love also to have those things optional/configurable in Fuel: optional cycle detection and optional class reshape support :) then we should be able to replace all the reference stream and smart by fuel. Yes, but Fuel is not completly ready to fully replace them. There are some hooks they provide that Fuel does not yet. But we will get there at some point. stef -- Mariano http://marianopeck.wordpress.com

Dec. 11, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Javier PimÃ¡s

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

Dec. 11, 2011

Re: [Pharo-project] NBCairo

by Javier PimÃ¡s

Excelent! this is really good! I added you to the NBCairo admins, can you copy them to squeaksource? (I have a really crappy internet connection right now) Cheers, Javier On 12/11/11, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Hi, Javier i've enhanced a bit the NBCairo bindings. > > Made the examples work with FS and directly display on the Display, > without creating an ImageMorph, and also release the png's. > I've changed the protocol of NBCairo, and updated it to subclass > NBExternalLibrary, now present in NB. > > I've attached the monticello packages, let me know what do you think. > > Fernando > pd: almost have the pango bindings working, screenshots soon. > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Dec. 11, 2011

[Pharo-project] [update 1.4] #14256

by Marcus Denker

14256 ----- Issue 5086: remove #associationDeclareAt: http://code.google.com/p/pharo/issues/detail?id=5086 Issue 5090: remove a call to withAllSuperAndSubclassesDoGently: http://code.google.com/p/pharo/issues/detail?id=5090 Issue 5088: TextStyleTest is empty. Remove http://code.google.com/p/pharo/issues/detail?id=5088 Issue 5074: Move Object>>#copyTwoLevel to finder package http://code.google.com/p/pharo/issues/detail?id=5074 Issue 4840: Schedule>>between:and:do can iterate over the wrong dates. http://code.google.com/p/pharo/issues/detail?id=4840 Issue 5089: clean unused methods related to filter streaming http://code.google.com/p/pharo/issues/detail?id=5089 -- Marcus Denker -- http://marcusdenker.de

Dec. 11, 2011

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by Schwab,Wilhelm K

Options are good. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] Sent: Sunday, December 11, 2011 7:59 AM To: Pharo-project(a)lists.gforge.inria.fr; fernando.olivero(a)usi.ch Subject: Re: [Pharo-project] [ANN] Eclipse Icons for Pharo 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 >>> >> >> >

Dec. 11, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by StÃ©phane Ducasse

> > >> Now how can we make progress if we do not change Pharo? > > Again, we already discussed this many times. I think Pharo is totally > off the track: Pharo should concentrate on getting a stable core and > enabling distributions on top, not on integrating as much new things > as possible. How can we remove from the kernel the ugly browser classes and tools, if people do not support the new tools? How can we redo senders and implementors (fix the ugly listMorph treemorph) when we cannot maintain OB (because we do not understand it)? So we are probably not so off-track that you believe. It will take more time that if people would collaborate with us, but we will get there. Ok so this is my last mail on that topic. I lost already too much energy that I should have spent on 1.4. Stef

Dec. 11, 2011

Re: [Pharo-project] Do we need the URI Package?

by Sven Van Caekenberghe

On 11 Dec 2011, at 11:38, Marcus Denker wrote: > Hi, > > There are three packages concerned with URLs: > > -> ZnUrl in Zinc > -> Network-URI > -> Network-Url > > URI was a package from Impara that was used extensively in all Impara products and Sophie... back than, > the idea was to integrate Impara infrastructure in Squeak, but that did not happen due to politics... > > Network-URI seems to be used nowhere in the system, so I guess we can remove it? Or is anyone using it? ZnUrl started as a copy of Seaside's WAUrl. From the class comment: I am ZnUrl, an implementation of an interpreted HTTP(S) URL/URI. Contrary to other implementations, this one is specific for HTTP(S). In other words, it might not be general enough, although I think it is better in its domain. Covering all possible URI/URL types over all kinds of applications is not simple. Yes, we need to simplify this, but it is a lot of work. Maybe we could have a look at what other libraries do. Sven

Dec. 11, 2011

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by Schwab,Wilhelm K

Some specific constructive feedback: the ones that "don't work" (IMHO) are the debug and profile icons. Overall, great job! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Sunday, December 11, 2011 4:04 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Eclipse Icons for Pharo On 11 Dec 2011, at 03:15, Esteban Lorenzano wrote: > Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... Great initiative! I personnaly don't like each of them, but these icons form a big, consistent set and make a good modernization of the UI. We should take this as a start and go over all missing ones, and maybe add a few unique once. Thanks. Sven

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by StÃ©phane Ducasse

On Dec 11, 2011, at 4:54 PM, Mariano Martinez Peck wrote: > > > On Sun, Dec 11, 2011 at 4:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 11, 2011, at 4:26 PM, Mariano Martinez Peck wrote: > > > > > > > On Sun, Dec 11, 2011 at 11:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Indeed this is fun I was doing the same :) > > Now I do not understand why some parts of the system uses dataStream, others ReferenceStream and finally others SmartRefStream > > why not all of them use SmartRefStream. > > > > It is not that I like these guys, but their class comments are pretty clear: > > - DataStream does NOT handle cycles, but hence it may be faster in certain scenarios. I guess that for example, Monticello is sure that in its definitions, there cannot be cycles. In addition, it doesn't take into account variables names/order and hence class reshape isn't supported. > > - ReferenceStream supports cycles but still doesn't support class reshape. > > - SmartRefStream supports cycles and class reshape. > > > sounds good > > Yes it does. In fact, I would love also to have those things optional/configurable in Fuel: optional cycle detection and optional class reshape support :) > > then we should be able to replace all the reference stream and smart by fuel. > > Yes, but Fuel is not completly ready to fully replace them. There are some hooks they provide that Fuel does not yet. But we will get there at some point. we will have because we do not want to stay indefinitely with image segment and smart ref. :) > > > stef > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 11, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by StÃ©phane Ducasse

All the compilation chain and code management and manipulation tools should be able to work on remote environment. We already discussed and I do not have the time to explain that the design of john was not taking into account that we would like to be able to work with one tool on another environment. The Browser environment = the complete code in the image does not work anymore. Anyway you do not want to change and this is perfect. It is just raging that I do not have enough time to fix it. Now we will see in 1.4 if people want to still use 1.3 or if they have benefit to work with 1.4. We integrated RB because we need to be able to move forward. It would be easy to have two configurations one for 1.3 and one for 1.4 but since you do not want to maintain it when you change your versions then we have to spend more time and frustration but we will do it. I spent a full day the last time while it would have cost you may be 10 min but I have no problem with that since the only thing I can do is to do it, I will do it. We will continue to work and push pharo and people can continue to use it or not. We know where we want to go and we will take responsibility and probably it will burn a bit more of our energy but there is no other paths sadly. Stef On Dec 11, 2011, at 4:42 PM, Lukas Renggli wrote: >> This is important for us to know that and this is a really nice stab >> in our back and this will kill a lot of the effort we build over the years. > > I don't understand why you think this is a stab into your back? I have > repeated the same concerns over and over again. > >> Now how can we make progress if we do not change Pharo? > > Again, we already discussed this many times. I think Pharo is totally > off the track: Pharo should concentrate on getting a stable core and > enabling distributions on top, not on integrating as much new things > as possible. > >> May be a dead pharo is better for you. > > A dead Pharo is not my goal. I need a minimal Pharo with an absolutely > trusted and stable core; a system where I can load all my code; a > system that does not force me to use things I don't want to use. > >> @Lukas: please, could you point out what are the expected problems? >> For example, all PetitParser-Tests are green out of the box in the latest 1.4. > > Nice, maybe the others also just work? > > OB does not work though because Polymorph changed (and the debugger > doesn't even open in the UI thread anymore either, so it is not > possible to figure out the problem); and because it expects a > different version of RB. > >> You were against changing RB, so how can we do remote tooling? > > I was against chaining RB, because the proposed changes undermined > design decisions in RB. In general, it feels extremely strange to me > if people change code (or even class comments) without understanding > the code. > > Also, for that matter, I don't see how you want to use RB for remote > tooling? If you remember, I pointed out an interview a while ago with > John where they discuss why remote tooling wouldn't work without > rewriting most parts. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 11, 2011