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

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

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

by Esteban Lorenzano

> 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. > > 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 > 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. 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) 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. 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

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

by phil＠highoctane.be

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. Is there a reason why Smalltalkhub would not stay working nicely? Are we talking about using bigger boxes here? Or is it a deeper issue? 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

OSWindow WithOpenGL

by Yuriy Tymchuk

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 kilon alios

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