July 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] a test

by Damien Cassou

a successful one -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 28, 2012

[Pharo-project] a test

by StÃ©phane Ducasse

July 28, 2012

Re: [Pharo-project] markdown to latext and html

by StÃ©phane Ducasse

ah like that. Why not. I would just get a document so that I can play after with the latex conversion. Stef > Precisely. And ideally, also support a pier syntax extension to point > to source code, or other interesting smalltalk objects. > > Doru > > > On Fri, Jul 27, 2012 at 2:22 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> On Fri, Jul 27, 2012 at 1:38 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> I meant that you can use the Pier engine, not the web editor. It's a >>> really nice model and it would be great to have it used more deeply >>> for documentation. >> >> do I get your opinion correctly if I summarize it as >> >> writing a program that takes a pier file as input and produces a latex >> file as output, and implementing this program based on Pier engine >> >> ? >> >> It makes sense and I already did something like this for textlint for Emacs >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

July 27, 2012

Re: [Pharo-project] a little pearl from SystemProgressMorph

by StÃ©phane Ducasse

On Jul 27, 2012, at 2:56 PM, Tudor Girba wrote: > I think you missed my p.s. :) No I saw it. Don't worry :) > > Doru > > > On Fri, Jul 27, 2012 at 2:21 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> On Jul 27, 2012, at 1:06 PM, Tudor Girba wrote: >> >>> I checked in Pharo 2.0, and it looks ... well, how should I put it: >>> it's confusing. You took a clear piece of code that could be printed >>> on a nice A4 paper, and transformed it into a myriad of delegations. >>> >>> I think you are just too afraid of if-statements. Clearly, a better >>> solution would have been to just use caseOf:. >> >> I did not check the code but using blocks as objects was a bad idea. >> >>> >>> Doru >>> >>> p.s. :) >>> >>> >>> On Thu, Jul 26, 2012 at 8:55 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> And I removed the strip behavior. >>>> In 2.0 it is not there. >>>> >>>> Stef >>>> >>>> On Jul 25, 2012, at 4:47 PM, Tudor Girba wrote: >>>> >>>>> Just for fun read the below piece of code :) >>>>> >>>>> >>>>> SystemProgressMorph>>label: shortDescription min: startMinValue max: >>>>> startMaxValue >>>>> "Answer the block that updates the progress bar." >>>>> >>>>> "some fun stuff added (by kph) >>>>> >>>>> - bar value: #label. - tell me my current label. >>>>> - bar value: 'newLabel'. - enable changing the label from within the workBlock >>>>> - bar value: #increment. - enable progress by one without keeping a counter >>>>> - bar value: #decrement. - go backwards (if you really have to, >>>>> useful for an abort, or rollback)! >>>>> >>>>> - bar value: newBigNum. - change the max on the fly - when you find >>>>> there is more to do. >>>>> - bar value: (bar value: #setMax) + 20 - change the max on the fly - >>>>> when you find there is more/less to do. >>>>> - bar value: (bar value: #setMin) - 20 - change the min on the fly - >>>>> not sure why you would want to. >>>>> " >>>>> | slot range barSize lastRefresh maxValue minValue bar| >>>>> maxValue := startMaxValue. >>>>> minValue := startMinValue. >>>>> ((range := maxValue - minValue) <= 0 or: [(slot := self nextSlotFor: >>>>> shortDescription) = 0]) >>>>> ifTrue: [^[:barVal| 0 ]]. >>>>> self recenter. >>>>> self openInWorld. >>>>> barSize := -1. "Enforces a inital draw of the morph" >>>>> lastRefresh := Time millisecondClockValue. >>>>> bar := bars at: slot. >>>>> ^[:barValArg | | barVal return newBarSize | >>>>> barVal := barValArg. >>>>> return := nil. >>>>> bar := bars at: slot. >>>>> "new fun stuff here" >>>>> barVal == #current ifTrue: [ return := barSize ]. >>>>> barVal == #label ifTrue:[ return := (labels at: slot) contents ]. >>>>> barVal == #setMax ifTrue: [ return := maxValue. maxValue := minValue ]. >>>>> barVal == #setMin ifTrue: [ return := minValue. minValue := maxValue ]. >>>>> barVal == #increment ifTrue: [return := barVal := barSize + 1]. >>>>> barVal == #decrement ifTrue: [ return := barVal := barSize - 1]. >>>>> (barVal isString and: [barVal isSymbol not]) ifTrue: [ >>>>> (labels at: slot) contents: barVal. >>>>> barVal := #refresh]. >>>>> barVal == #refresh ifTrue: [self currentWorld displayWorld. return := true]. >>>>> (barVal == SmallInteger maxVal or: [ barVal == #finished ]) ifTrue: >>>>> [return := slot]. >>>>> return ifNil: [ >>>>> barVal > maxValue ifTrue: [return := maxValue := barVal]. >>>>> barVal < minValue ifTrue: [return := minValue := barVal]. >>>>> (barVal between: minValue and: maxValue) >>>>> ifTrue: [newBarSize := (barVal - minValue / range * BarWidth) truncated. >>>>> newBarSize = barSize >>>>> ifFalse: [barSize := newBarSize. >>>>> (Time millisecondsSince: lastRefresh) > 25 >>>>> ifTrue: [barVal := #refresh ]]]. >>>>> barVal == #refresh ifTrue: [ >>>>> ((bar valueOfProperty: #useStripes) ifNil: [false]) >>>>> ifTrue: [bar fillStyle origin: bar position - ((Time >>>>> millisecondClockValue // 50 \\ 30) @ 0)]. >>>>> bar barSize: barSize. >>>>> self currentWorld displayWorld. >>>>> lastRefresh := Time millisecondClockValue]]. >>>>> return] >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

July 27, 2012

[Pharo-project] [update 2.0] #20236

by Esteban Lorenzano

20236 ----- Issue 6467: Remove SystemChangeNotifier 2 - All events using SystemAnnouncer http://code.google.com/p/pharo/issues/detail?id=6467 the beast is not dead yet... but almost :)

July 27, 2012

[Pharo-project] [update 2.0] #20235

by Esteban Lorenzano

20235 ----- Issue 6467: Remove SystemChangeNotifier 2 - All events using SystemAnnouncer http://code.google.com/p/pharo/issues/detail?id=6467 (just loading a method needed, still not finished)

July 27, 2012

Re: [Pharo-project] Strange behavior of Metacello in Pharo 2.0

by Alexandre Bergel

Thanks, I will try Cheers, Alexandre On Jul 27, 2012, at 1:05 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Alexandre Bergel-7 wrote >> >> http://code.google.com/p/pharo/issues/detail?id=6446 >> > > Just so we can continue to get things done, a temporary workaround is to > explicitly load Metacello instead of letting it bootstrap: > > Gofer it > url: 'http://seaside.gemstone.com/ss/metacello'; > package: 'ConfigurationOfMetacello'; > load. > > (Smalltalk at: #ConfigurationOfMetacello) project stableVersion load: > 'batch'. > > > > -- > View this message in context: http://forum.world.st/Strange-behavior-of-Metacello-in-Pharo-2-0-tp4641098p… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 27, 2012

Re: [Pharo-project] Strange behavior of Metacello in Pharo 2.0

by Sean P. DeNigris

Alexandre Bergel-7 wrote > > http://code.google.com/p/pharo/issues/detail?id=6446 > Just so we can continue to get things done, a temporary workaround is to explicitly load Metacello instead of letting it bootstrap: Gofer it url: 'http://seaside.gemstone.com/ss/metacello'; package: 'ConfigurationOfMetacello'; load. (Smalltalk at: #ConfigurationOfMetacello) project stableVersion load: 'batch'. -- View this message in context: http://forum.world.st/Strange-behavior-of-Metacello-in-Pharo-2-0-tp4641098p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 27, 2012

[Pharo-project] Jenkins home folder almost full

by Sean P. DeNigris

>From https://ci.lille.inria.fr/pharo/manage : Your Jenkins data directory "/net/www/ci/pharo/.jenkins" (AKA JENKINS_HOME) is almost full. You should act on it before it gets completely full. -- View this message in context: http://forum.world.st/Jenkins-home-folder-almost-full-tp4641876.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 27, 2012

Re: [Pharo-project] Google Code labels/templates

by Sean P. DeNigris

Sean P. DeNigris wrote > > The... Types are Bug, Enhancement, Cleanup, Feature [1]. Nautilus and > Jenkins [2] really don't fit into this framework. Maybe because there will > be many fewer issues, we don't need the level of granularity of [1] for > [2]. But when we get close to a release, it'd be nice to know that there > is 1 Nautilus bug and 10 Enhancements pending (i.e. probably only one > critical thing) vs. 11 Type-Nautilus. > > So, now that I said all that, it seems the most powerful/flexible approach > would be to leave the "nautilus" tag, remove the leading "Type-" from > "Type-[Jenkins|Spec|Seed]", and then to make templates for > Jenkins/Spec/Seed like the one for Nautilus. > I moved Types that are really sub-tools/topics to Targets (you can pick one Target per issue): Target-Seed = Bootstrap oriented Target-Filesystem Target-Spec Target-Jenkins = CI related stuff Target-Nautilus We now have the following types (you can pick one Type per issue): Type-Bug = Report/fix of a software defect Type-Cleanup = Change that does not functionally modify existing Type-Feature = New Feature Type-HighLevelTask = Work item that doesn't change the code or docs Type-Enh = Little Enhancement Type-FailingTest = There is a test for this bug that fails I updated all existing issues/templates that seemed relevant to use the new labels. Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-labels-templates-tp4636767p4641868.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 27, 2012