November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo Mission Statement (http://www.pharo-project.org/home)

by Marcus Denker

On 24 Nov 2013, at 23:08, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > You might classify this as nit-picking, but I think the second-to-last > word should be deleted: > > Mission > Pharo's goal is to deliver a clean, innovative, free open-source > Smalltalk-inspired environment. By providing a stable and small core > system, excellent dev tools, and maintained releases, Pharo is an > attractive platform to build and deploy mission critical Smalltalk > applications. > fixed.

Nov. 25, 2013

Re: [Pharo-dev] what unload does?

by Marcus Denker

On 24 Nov 2013, at 22:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Stupidly I was thinking that unload was removing classes from the system. > > but (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload. > does not remove the classes from the system > > is it me or it was working? > It seems to work for meâ¦ I get a FallBack world menu after and the package seems to be unloaded. (of course there will be obsolete classes still around as other packages subclass from classes of this). ScriptLoaderâs #unloadPackageNamed: does the same and I used it a lot. Marcus

Nov. 25, 2013

Re: [Pharo-dev] about miniimage

by Pavel Krivanek

Hi Stef, our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users - than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload. Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting. >From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy. -- Pavel 24. 11. 2013 v 22:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi pavel > > may be I should start from your miniimage and start to making sure that the configurations can load then in a second step > I can make sure that they can unload. > > What do you think? > > Stef

Nov. 25, 2013

Re: [Pharo-dev] SLICE-Issue-12179-Nautilus-Add-package-filter-input-box

by Benjamin

I would have been more efficient to wait till a new slice is proposed. If you want to focus on you project instead of loosing time resolving conflicts about thing you do not have knowledge about I think a good way to save time is to let people knowing resolving merge conflict, aka the guy who proposed a fix. Otherwise, you (and any integrator) will have to know everything about the whole system, and this will never happen. The monkey is here to show the contributors that what they propose is not working properly. Loading slices with conflicts can only lead to reverting code. And doing the same things again and again when you think it is in the system is far worse that proposing a new version up to date of a slice, since usually the feedback provided by the infrastructure takes a couple of minute while chasing accidentally rollback fixes may take much longer. Ben On 24 Nov 2013, at 22:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>>> I would like, but I have not found out how. I will take care of it and ask in mailing list. >>>> >>>> Anyway, I am not sure if it was well integrated. >>> >>> There was a conflict and I fully loaded your code. So I do not see how it could be different. >>> But with computer science everything is possible. >> >> Why loading it if there was a conflict ? > > Do you really think that as an integrator we never chose which method to integrate and that we never handle conflicts? > The version I selected is correct and working this is just an unused variable. > > Now if you want I can also stop looking at any bug entry and stop to integrate fix and focus on my own project. > You will see if will take more time to get things integrated and do not believe that automatically validated means something > when we are talking about certain aspects of the system. > No need to rant that nobody take cares of integrating bugs. > > Living is taking action. > > Stef

Nov. 25, 2013

Pharo Mission Statement (http://www.pharo-project.org/home)

by Paul Davidowitz

You might classify this as nit-picking, but I think the second-to-last word should be deleted: Mission Pharo's goal is to deliver a clean, innovative, free open-source Smalltalk-inspired environment. By providing a stable and small core system, excellent dev tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical Smalltalk applications.

Nov. 24, 2013

Re: [Pharo-dev] Is there an up to date version of ConfigurationOfFuel?

by StÃ©phane Ducasse

thanks Stef On Nov 24, 2013, at 10:52 PM, Max Leske <maxleske(a)gmail.com> wrote: > Iâm currently making some fixes to the configuration but basically you can just use the latest one. That should do the trick. > > On 24.11.2013, at 22:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >>> What do you mean by up to date? For 3.0 #development is current. >> >> I want to try to unload fuel and reload it. I guess that it will be easy since you maintain it. >> I want to do that to many parts (all) of the system. >> >>>> Is there an up to date version of ConfigurationOfFuel? >> > >

Nov. 24, 2013

what unload does?

by StÃ©phane Ducasse

Stupidly I was thinking that unload was removing classes from the system. but (MCWorkingCopy forPackage: (MCPackage named: 'NautilusCommon')) unload. does not remove the classes from the system is it me or it was working? Stef

Nov. 24, 2013

Re: [Pharo-dev] The Second Coming of Java article

by Jan Vrany

On 24/11/13 21:19, askoh wrote: > http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/ > > The article talks about Java Virtual Machine running dynamic languages like > Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual > Machine from running Java, Scala, Clojure and other JVM languages? Is that > something we can ride on to greater awareness and usage of Smalltalk Virtual > Machine and Smalltalk? Well, nothing atually:-) It's already done. Smalltalk/X virtual machine can run Java bytecode and thus all sort of JVM languages :-) Cheers, Jan [1] https://swing.fit.cvut.cz/projects/stx-libjava [2] Marcel Hlopko, Jan KurÅ¡, Jan VranÃ½, and Claus Gittinger. On the Integration of Smalltalk and Java Ì http://www.esug.org/wiki/pier/Conferences/2012/International-Workshop---IWS… , page 1 :-) [3] http://www.youtube.com/watch?v=p21z3bAt7b0&list=PLCGAAdUizzH027lLWKXh_44cGu… [4] https://www.youtube.com/watch?v=p3J554BNEz8 > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 24, 2013

Re: [Pharo-dev] Better layout definition in new Nautilus Browser with filter dialog

by Juraj Kubelka

Thanks Benjamin :-) Jura El 24-11-2013, a las 17:47, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> escribiÃ³: > I will do that tomorrow :P > > Do not hesitate to bump me if you forget :) > > Ben > > On 24 Nov 2013, at 21:38, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> Hi >> >> I do not know how to do the better layout of input package filter which was integrated to latest Pharo 3.0 image. >> >> It is defined in method PackageTreeNautilusUI>>buildFirstColumn: (it means package column) >> And code looks like: >> >> ^ PanelMorph new >> changeProportionalLayout; >> addMorph: self buildPackageSearch â <ââ this is new filter input dialog" >> fullFrame: ((0@0 corner: 1(a)0.1)) â and his layout definition" >> addMorph: self buildList â <ââ this is package listâ >> fullFrame: ((0(a)0.1 corner: 1@1) asLayoutFrame bottomOffset: -25); â and his layout definition" >> addMorph: buttons â <ââ Hierarchy button" >> fullFrame: ((0@1 corner: 1@1) asLayoutFrame topOffset: -25); â and his layout" >> hResizing: #spaceFill; >> vResizing: #spaceFill; >> yourself. >> >> >> So, now filter dialog and package list are flexible and change their height according to window size. >> I have tried to define input dialog of fixed size (according to font size), but I do not know how. >> Any suggestion? >> >> Thanks, >> Jura >

Nov. 24, 2013

Re: [Pharo-dev] Is there an up to date version of ConfigurationOfFuel?

by Max Leske

Iâm currently making some fixes to the configuration but basically you can just use the latest one. That should do the trick. On 24.11.2013, at 22:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> What do you mean by up to date? For 3.0 #development is current. > > I want to try to unload fuel and reload it. I guess that it will be easy since you maintain it. > I want to do that to many parts (all) of the system. > >>> Is there an up to date version of ConfigurationOfFuel? >

Nov. 24, 2013