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

Re: [Pharo-dev] Some STON Changes

by stepharo

we will have to udpate the chapter. I added the text in the chapter :) Stef Le 27/11/14 12:03, Sven Van Caekenberghe a Ã©crit : > Hi, > > Christophe Demarey had a nice idea (and he implemented it too!) that extends the syntax (or more precisely, the usage of the syntax) of STON a bit, and I just integrated it. Thank you, Christophe ! > > His core idea is to use the colon syntax for Associations. So now you can also write: > > #foo:1 > > which will become > > #foo->1 > > and vice versa. > > This does not change the way maps (either for dictionaries or arbitrary objects) work. In practice, this means that there are now 2 closely related expressions: > > STON fromString: '[ #foo:1, #bar:2 ]'. > > => { #foo->1. #bar->2 } > > STON fromString: '{ #foo:1, #bar:2 }'. > > => a Dictionary(#bar->2 #foo->1 ) > > In the first case you get an Array of explicit Associations, in the second case you get a Dictionary which uses Associations internally, but that is an implementation detail. And of course you can send #asDictionary to the array. > > Note that nesting is also possible ;-) > > #foo : 1 : 2 > > means > > #foo->(1->2) > > Anyway, I think from a Smalltalk perspective this is totally cool. As far as I can see, this addition does not result in conflicts. > > Another addition that was requested by Christophe that I added was a way to control which instance variables get written and/or the order in which they get written. > > This can be done by overwriting Object class>>#stonAllInstVarNames

Nov. 27, 2014

Re: [Pharo-dev] Pharo-4.0-Update-Step-3-Minimal versus MCWorkingCopyBrowser

by stepharo

Le 27/11/14 17:23, Ben Coman a Ã©crit : > Awesome! Thanks for your effort getting it through. No we thank you! > > Marcus Denker wrote: >> Yes! Build was a success. Good :-) >>> On 27 Nov 2014, at 15:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Hi, >>> >>> I am integrating this now as 40 #387 >>> >>> I made the changed to the shrink script, we soon will see if it workedâ¦ >>> >>> Marcus >>> >>>> On 26 Nov 2014, at 15:36, Ben Coman <btc(a)openInWorld.com> wrote: >>>> >>>> >>>> I am checking why the .10 slice for >>>> Issue-14261-Delay-refactoring-part-1 >>>> is breaking build of the Jenkins > Pharo-4.0-Update-Step-3-Minimal. >>>> >>>> As an aside, I discovered opening (and closing) Monticello in the >>>> image prior to running shrink.st makes it fragile. >>>> >>>> With the scripts for build 40384 from... >>>> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-3-Minimal/243/ >>>> 1. I opened the 40384.image with pharo-ui >>>> 2. Opened Monticello and browsed to the .10 slice of issue 14261 >>>> but did not load it >>>> 3. Saved the image >>>> 4. Ran my cobbled ./shrink.sh shown here... >>>> >>>> #!/bin/bash -x >>>> IMAGE=Pharo-minimal >>>> # wget -O - http://get.pharo.org/vm | bash >>>> ./pharo *.image save $IMAGE --delete-old >>>> ./pharo $IMAGE.image unloadNB.st >>>> ./pharo $IMAGE.image cleanAfterNB.st >>>> ./pharo $IMAGE.image prepareShrink.st >>>> ./pharo $IMAGE.image shrink.st >>>> >>>> which fails with... >>>> 11 IndentingListItemMorph(Object)>>doesNotUnderstand: #theme >>>> 12 IndentingListItemMorph(StringMorph)>>defaultColor >>>> 13 IndentingListItemMorph(Morph)>>initialize >>>> ... >>>> 23 MCWorkingCopyBrowser(Object)>>changed: >>>> >>>> >>>> shrink.st is more robust with the following... >>>> MCWorkingCopyBrowser allInstances do: [ >>>> :mcwcb | SystemAnnouncer uniqueInstance unsubscribe: mcwcb >>>> ]. >>>> >>>> added to shrink.st. I put it after existing line... >>>> SystemAnnouncer uniqueInstance unsubscribe: NOCCompletionTable. >>>> >>>> HTH, >>>> cheers -ben >>>> >> >> >> > > > >

Nov. 27, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by stepharo

Nice to know that you run successful web apps. > People on this list used to say the same about squeaksource.com. But it > has been working flawlessly since it got updated to the latest version > (which implies that a few bugs got fixed). > > What makes you think that tracking down the bugs in SmalltalkHub and > fixing them wouldn't be enough? > > Based on my experience a single image - running well designed software > - is able to serve about ten million requests a day. I think that the > actual load on smalltalkhub.com is about three magnitudes lower than > that. > > Levente A part of our problem is maintenance and the fact that Smalltalkhub is missing some features and composed of several layers (amber using bower, mongo, pharo...) and that it is using an old version of amber. Now if somebody wants to help it would be great. Probably a seaside version would reduce the stack dependency. We are flooded by work. Stef

Nov. 27, 2014

Re: [Pharo-dev] OSWindow WithOpenGL

by stepharo

Pay attention because OSWindow needs some love and code review. Stef Le 27/11/14 18:58, Ronie Salgado a Ã©crit : > Try loading the latest version of ConfigurationofOSWindow in > Pharo/OSWindow (SmalltalkHub). That one should have that group. > > Greetings, > Ronie > > 2014-11-27 10:33 GMT-03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com > <mailto:yuriy.tymchuk@me.com>>: > > Hi, Iâm trying to load Woden and encounter a problem because it > refers to âWithOpenGLâ group of OSWindow configuration and there > is not one like that. Has anything changed? What should we use not? > > Cheers! > Uko > >

Nov. 27, 2014

Re: [Pharo-dev] OSWindow WithOpenGL

by Ronie Salgado

Try loading the latest version of ConfigurationofOSWindow in Pharo/OSWindow (SmalltalkHub). That one should have that group. Greetings, Ronie 2014-11-27 10:33 GMT-03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, Iâm trying to load Woden and encounter a problem because it refers to > âWithOpenGLâ group of OSWindow configuration and there is not one like > that. Has anything changed? What should we use not? > > Cheers! > Uko >

Nov. 27, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban Lorenzano

> On 27 Nov 2014, at 17:15, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Thu, Nov 27, 2014 at 04:19:20PM +0100, Esteban Lorenzano wrote: >> >>> On 27 Nov 2014, at 16:05, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Thu, 27 Nov 2014, Noury Bouraqadi wrote: >>> >>>> SmalltalkHub is slow, so don?t click too fast :-( >>>> >>>> While I?m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don?t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... >>> >>> People on this list used to say the same about squeaksource.com. But it >>> has been working flawlessly since it got updated to the latest version >>> (which implies that a few bugs got fixed). >>> >>> What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough? >>> >>> Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that. >> >> because: >> 1) the reason why squeaksource survived is because there is an smalltalkhub absorbing most of the packages. > > No. The reason that squeaksource.com survived is that someone decided to put > effort into maintaining it. well, thatâs your perception. Mine is that sthub took out from ss 150k packages, and all pharo infrastructure requirements (a lot, believe meâ¦ we are almost 24h/7 downloading packages and running different processes). stillâ¦if you put enough effort you can keep anything running, of course. But you will always need that extra effort. Thinking in the long term, that does not scales unless you have an organisation that scales. Or unless you have a community that does not change. I prefer to believe that all our predictions will become small in time, and then I prefer to think that in the long term is better to have an up-to-date infrastructure, that is capable to absorb our growing without taking much effort from our part. ah, and btwâ¦ smalltalkhub works quite fine. It just have problems on safari, because of the version we are using of amber. then, is running in a virtualisation system, so time to time it becomes slow. we can fix the second one paying a better server :) Esteban > > The same will be true for SmalltalkHub. If you decide to make it work, then > you will succeed. If you decide that it is not worth the effort, then it will > fail. > > Dave > > >> 2) I never say it was not possible to keep it running. I said it does not worth the effort, which is a complete different thing. Of course, if someone wants to take smalltalkhub (there is even a configuration for it) and fix the problems that emerge, I will be more than happy to update the production image. >> >> Esteban >> >>> >>> Levente >>> >>>> >>>> It?s better to use some mainstream platform such as github. >>>> We?ll we have support for it in Pharo 4? >>>> >>>> It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. >>>> >>>> Noury >> >

Nov. 27, 2014

Re: [Pharo-dev] Pharo-4.0-Update-Step-3-Minimal versus MCWorkingCopyBrowser

by Ben Coman

Awesome! Thanks for your effort getting it through. Marcus Denker wrote: > Yes! Build was a success. Good :-) >> On 27 Nov 2014, at 15:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> I am integrating this now as 40 #387 >> >> I made the changed to the shrink script, we soon will see if it workedâ¦ >> >> Marcus >> >>> On 26 Nov 2014, at 15:36, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> >>> I am checking why the .10 slice for Issue-14261-Delay-refactoring-part-1 >>> is breaking build of the Jenkins > Pharo-4.0-Update-Step-3-Minimal. >>> >>> As an aside, I discovered opening (and closing) Monticello in the image prior to running shrink.st makes it fragile. >>> >>> With the scripts for build 40384 from... https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-3-Minimal/243/ >>> 1. I opened the 40384.image with pharo-ui >>> 2. Opened Monticello and browsed to the .10 slice of issue 14261 >>> but did not load it >>> 3. Saved the image >>> 4. Ran my cobbled ./shrink.sh shown here... >>> >>> #!/bin/bash -x >>> IMAGE=Pharo-minimal >>> # wget -O - http://get.pharo.org/vm | bash >>> ./pharo *.image save $IMAGE --delete-old >>> ./pharo $IMAGE.image unloadNB.st >>> ./pharo $IMAGE.image cleanAfterNB.st >>> ./pharo $IMAGE.image prepareShrink.st >>> ./pharo $IMAGE.image shrink.st >>> >>> which fails with... >>> 11 IndentingListItemMorph(Object)>>doesNotUnderstand: #theme >>> 12 IndentingListItemMorph(StringMorph)>>defaultColor >>> 13 IndentingListItemMorph(Morph)>>initialize >>> ... >>> 23 MCWorkingCopyBrowser(Object)>>changed: >>> >>> >>> shrink.st is more robust with the following... >>> MCWorkingCopyBrowser allInstances do: [ >>> :mcwcb | SystemAnnouncer uniqueInstance unsubscribe: mcwcb >>> ]. >>> >>> added to shrink.st. I put it after existing line... >>> SystemAnnouncer uniqueInstance unsubscribe: NOCCompletionTable. >>> >>> HTH, >>> cheers -ben >>> > > >

Nov. 27, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by David T. Lewis

On Thu, Nov 27, 2014 at 04:19:20PM +0100, Esteban Lorenzano wrote: > > > On 27 Nov 2014, at 16:05, Levente Uzonyi <leves(a)elte.hu> wrote: > > > > On Thu, 27 Nov 2014, Noury Bouraqadi wrote: > > > >> SmalltalkHub is slow, so don?t click too fast :-( > >> > >> While I?m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don?t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... > > > > People on this list used to say the same about squeaksource.com. But it > > has been working flawlessly since it got updated to the latest version > > (which implies that a few bugs got fixed). > > > > What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough? > > > > Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that. > > because: > 1) the reason why squeaksource survived is because there is an smalltalkhub absorbing most of the packages. No. The reason that squeaksource.com survived is that someone decided to put effort into maintaining it. The same will be true for SmalltalkHub. If you decide to make it work, then you will succeed. If you decide that it is not worth the effort, then it will fail. Dave > 2) I never say it was not possible to keep it running. I said it does not worth the effort, which is a complete different thing. Of course, if someone wants to take smalltalkhub (there is even a configuration for it) and fix the problems that emerge, I will be more than happy to update the production image. > > Esteban > > > > > Levente > > > >> > >> It?s better to use some mainstream platform such as github. > >> We?ll we have support for it in Pharo 4? > >> > >> It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. > >> > >> Noury >

Nov. 27, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban Lorenzano

> On 27 Nov 2014, at 16:05, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Thu, 27 Nov 2014, Noury Bouraqadi wrote: > >> SmalltalkHub is slow, so donât click too fast :-( >> >> While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... > > People on this list used to say the same about squeaksource.com. But it > has been working flawlessly since it got updated to the latest version > (which implies that a few bugs got fixed). > > What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough? > > Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that. because: 1) the reason why squeaksource survived is because there is an smalltalkhub absorbing most of the packages. 2) I never say it was not possible to keep it running. I said it does not worth the effort, which is a complete different thing. Of course, if someone wants to take smalltalkhub (there is even a configuration for it) and fix the problems that emerge, I will be more than happy to update the production image. Esteban > > Levente > >> >> Itâs better to use some mainstream platform such as github. >> Weâll we have support for it in Pharo 4? >> >> It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. >> >> Noury

Nov. 27, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Levente Uzonyi

On Thu, 27 Nov 2014, Noury Bouraqadi wrote: > SmalltalkHub is slow, so donât click too fast :-( > > While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... People on this list used to say the same about squeaksource.com. But it has been working flawlessly since it got updated to the latest version (which implies that a few bugs got fixed). What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough? Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that. Levente > > Itâs better to use some mainstream platform such as github. > Weâll we have support for it in Pharo 4? > > It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. > > Noury >

Nov. 27, 2014