- Pharo-dev - lists.pharo.org

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

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

by Esteban Lorenzano

> On 27 Nov 2014, at 15:53, phil(a)highoctane.be wrote: > > On Thu, Nov 27, 2014 at 3:37 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> On 27 Nov 2014, at 14:43, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> At times, mczs still come handy for some merges... >> >> And Smalltalkhub is good as a safe heaven for collecting packages that are otherwise scattered all around. > > nothing that a real catalog/centralised package manager alla npm/apt-get/etc cannot do it. > using a package manager as a catalog feels to me like hammering a screw. > > Sure, I am with you on that. I am yum - ing all day long :-) > > But as you know, the Pharo Catalog descriptions are quite lonely. > I'd like to take a moment to tackle that one. > > In fact, there are several concerns that I find (and other members on the list share the feeling) must be addressed for commercial development. > > e.g.: Stronger RDBMS support, AAA, Logs, ... > > But this not really Pharo per se, but a onion ring around it. > As you guys are doing 4.0, that onion ring is making 3.0 work for commercial stuff. > I think that we'll always be one version behind, which is ok. > > >> >> Is there a reason why Smalltalkhub would not stay working nicely? > > because we do not have the strength/willing to maintain it. > and each day we are: farther from âstate of the artâ source management, and farther from state of the art javascript, etc. (which is the reason why sthub > > Ok, thx. > > >> Are we talking about using bigger boxes here? Or is it a deeper issue? > > keeping up-to-date a system like sthub is a lot of work, and takes a lot of time. > personally, I prefer way more to spend my time in things that will have a real impact in the community (like having a modern vm) than lose it trying constantly to catch up with what others (with a lot more resources) already did. > > Sure, modern vm anytime! > The git worklflow is superpowerful and that's what people use these days. > In a MOOC I do, all exercises and slideware are in Github... > > > each time I start a sub-project, my first question is: âthis stuff will have a multiplier effect in the community?â and second question is âdo we have to doit from scratch, or can we take advantage of other projects?â. As a maintainer, and being conscious of our limitations, this are the driving forces I find positive to work. > (and of course, most times I do not start sub-projects at all, I just jump into a burning place and try to do my best to fix itâ¦ not always very successfully :P) > > Nah, you rule. I wish I was as good as you are. > > > so, coming back to less âphilosophicalâ question: > > 1) do we need a state-of-the-art source code management? YES. > 2) do we want to spend the few manpower we have on running into a worst solution of what is already around? I think no. > > libgit2 would provide that without going through Github driver hoops, which is sweet and more welcoming to newcomers. and exactly there is where I will put my effort (as soon as I have time) :) In the long way, Iâm quite sure is a lot more important for community than patching sthub. btwâ¦ historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects" > > > Esteban > >> >> Phil >> >> >> >> >> >> On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently . >> >> If you are user of emacs there is magit , really powerful gui client and very popular among emacs users. >> >> For gui client I have used quite a lot SmartGit >> >> http://www.syntevo.com/smartgit/ <http://www.syntevo.com/smartgit/> >> >> and recently a fellow python developer introduced me to Sourcetree >> >> http://www.sourcetreeapp.com/ <http://www.sourcetreeapp.com/> >> >> Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github. >> >> But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process. >> > >

Nov. 27, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40387 Home: https://github.com/pharo-project/pharo-core

Nov. 27, 2014

[pharo-project/pharo-core] 865564: 40387

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 8655647afcc3b5483ed8637dd0fc45a32eed683d https://github.com/pharo-project/pharo-core/commit/8655647afcc3b5483ed8637d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-27 (Thu, 27 Nov 2014) Changed paths: M Kernel.package/Delay.class/class/enable new code/newCodeEnabled_.st A Kernel.package/Delay.class/class/timer process/restartTimerEventLoop.st M Kernel.package/Delay.class/class/timer process/runTimerEventLoop.st M Kernel.package/Delay.class/class/timer process/startTimerEventLoop.st R Kernel.package/Delay.class/class/timer process/startTimerEventLoop_.st M Kernel.package/Delay.class/class/timer process/stopTimerEventLoop.st M Kernel.package/Delay.class/instance/private/adjustResumptionTimeOldBase_newBase_.st M Kernel.package/Delay.class/instance/private/resumptionTime_.st M Kernel.package/Delay.class/instance/private/signalWaitingProcess.st M Kernel.package/Delay.class/instance/public/beingWaitedOn_.st A Kernel.package/Delay.class/instance/timer process/timingPriorityBeingWaitedOn_.st A Kernel.package/Delay.class/instance/timer process/timingPriorityResumptionTime_.st A Kernel.package/Delay.class/instance/timer process/timingPrioritySignalWaitingProcess.st A Kernel.package/DelayScheduler.class/instance/snapshotting/adjust_resumptionTimeOldBase_newBase_.st M Kernel.package/DelayScheduler.class/instance/snapshotting/restoreResumptionTimes.st M Kernel.package/DelayScheduler.class/instance/snapshotting/saveResumptionTimes.st M Kernel.package/DelayScheduler.class/instance/timer process/handleTimerEvent_.st A Kernel.package/DelayScheduler.class/instance/timer process/restartTimerEventLoop.st M Kernel.package/DelayScheduler.class/instance/timer process/runTimerEventLoop.st M Kernel.package/DelayScheduler.class/instance/timer process/scheduleDelay_.st M Kernel.package/DelayScheduler.class/instance/timer process/startTimerEventLoop.st R Kernel.package/DelayScheduler.class/instance/timer process/startTimerEventLoop_.st M Kernel.package/DelayScheduler.class/instance/timer process/stopTimerEventLoop.st M Kernel.package/DelayScheduler.class/instance/timer process/unscheduleDelay_.st M Kernel.package/DelayWaitTimeout.class/instance/signaling/signalWaitingProcess.st A Kernel.package/DelayWaitTimeout.class/instance/signaling/timingPrioritySignalWaitingProcess.st A Kernel.package/ManifestKernel.class/README.md A Kernel.package/ManifestKernel.class/class/meta data/rejectClasses.st A Kernel.package/ManifestKernel.class/class/meta data/rejectRules.st A Kernel.package/ManifestKernel.class/class/meta data/ruleConsistencyCheckRuleV1FalsePositive.st A Kernel.package/ManifestKernel.class/class/meta data/ruleEqualsTrueRuleV1FalsePositive.st A Kernel.package/ManifestKernel.class/class/meta data/ruleLongMethodsRuleV1FalsePositive.st A Kernel.package/ManifestKernel.class/definition.st M Kernel.package/MonitorDelay.class/instance/private/signalWaitingProcess.st A Kernel.package/MonitorDelay.class/instance/private/timingPrioritySignalWaitingProcess.st A Kernel.package/extension/Heap/instance/removeFirstOrNil.st M KernelTests.package/DelayBenchmark.class/instance/support/generateDelayProcesses_priority_maxDuration_fromSeed_.st A KernelTests.package/DelaySchedulerTest.class/instance/running/tearDown.st M KernelTests.package/DelaySchedulerTest.class/instance/tests/testMaxTickMoreThanDuration.st A KernelTests.package/DelaySchedulerTest.class/instance/tests/testTestInterferenceWithSystemTimingSemaphore.st A KernelTests.package/ManifestKernelTests.class/README.md A KernelTests.package/ManifestKernelTests.class/class/meta data/rejectClasses.st A KernelTests.package/ManifestKernelTests.class/class/meta data/rejectRules.st A KernelTests.package/ManifestKernelTests.class/definition.st A KernelTests.package/extension/Delay/class/testCaseSupportTimingSemaphore.st A KernelTests.package/extension/DelayScheduler/instance/testCaseSupportSystemTimingSemaphore.st A KernelTests.package/extension/DelayScheduler/instance/testCaseSupportTimingSemaphore.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script387.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40387.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-ImageCleaner.package/ImageCleaner.class/instance/cleaning/cleanUpMethods.st Log Message: ----------- 40387 14261 Delay refactoring (part 1) - move scheduler from class-side to instance-side of its own class https://pharo.fogbugz.com/f/cases/14261 http://files.pharo.org/image/40/40387.zip

Nov. 27, 2014

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

by phil＠highoctane.be

On Thu, Nov 27, 2014 at 3:37 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 27 Nov 2014, at 14:43, phil(a)highoctane.be wrote: > > At times, mczs still come handy for some merges... > > And Smalltalkhub is good as a safe heaven for collecting packages that are > otherwise scattered all around. > > > nothing that a real catalog/centralised package manager alla > npm/apt-get/etc cannot do it. > using a package manager as a catalog feels to me like hammering a screw. > Sure, I am with you on that. I am yum - ing all day long :-) But as you know, the Pharo Catalog descriptions are quite lonely. I'd like to take a moment to tackle that one. In fact, there are several concerns that I find (and other members on the list share the feeling) must be addressed for commercial development. e.g.: Stronger RDBMS support, AAA, Logs, ... But this not really Pharo per se, but a onion ring around it. As you guys are doing 4.0, that onion ring is making 3.0 work for commercial stuff. I think that we'll always be one version behind, which is ok. > > Is there a reason why Smalltalkhub would not stay working nicely? > > > because we do not have the strength/willing to maintain it. > and each day we are: farther from âstate of the artâ source management, > and farther from state of the art javascript, etc. (which is the reason why > sthub > Ok, thx. > > Are we talking about using bigger boxes here? Or is it a deeper issue? > > > keeping up-to-date a system like sthub is a lot of work, and takes a lot > of time. > personally, I prefer way more to spend my time in things that will have a > real impact in the community (like having a modern vm) than lose it trying > constantly to catch up with what others (with a lot more resources) already > did. > Sure, modern vm anytime! The git worklflow is superpowerful and that's what people use these days. In a MOOC I do, all exercises and slideware are in Github... > > each time I start a sub-project, my first question is: âthis stuff will > have a multiplier effect in the community?â and second question is âdo we > have to doit from scratch, or can we take advantage of other projects?â. As > a maintainer, and being conscious of our limitations, this are the driving > forces I find positive to work. > (and of course, most times I do not start sub-projects at all, I just jump > into a burning place and try to do my best to fix itâ¦ not always very > successfully :P) > Nah, you rule. I wish I was as good as you are. > > so, coming back to less âphilosophicalâ question: > > 1) do we need a state-of-the-art source code management? YES. > 2) do we want to spend the few manpower we have on running into a worst > solution of what is already around? I think no. > > libgit2 would provide that without going through Github driver hoops, which is sweet and more welcoming to newcomers. > Esteban > > > Phil > > > > > > On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> I forgot to add that git comes with excellent gui clients that are far >> more powerful and elegant that what Pharo offers currently . >> >> If you are user of emacs there is magit , really powerful gui client and >> very popular among emacs users. >> >> For gui client I have used quite a lot SmartGit >> >> http://www.syntevo.com/smartgit/ >> >> and recently a fellow python developer introduced me to Sourcetree >> >> http://www.sourcetreeapp.com/ >> >> Both are free for non commercial projects. They require a license for >> commercial use but they are relative cheap. They come with diff tools, easy >> commit access , branching, merging and tons of stuff to make life easier >> for complex scenarios and they integrate well with bitbucket and other >> online repositories besides github. >> >> But even from command line there is a lot of room for automation by >> creating bash scripts to make commits one step process. >> > > >

Nov. 27, 2014

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

by Marcus Denker

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] Pharo-4.0-Update-Step-3-Minimal versus MCWorkingCopyBrowser

by Marcus Denker

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