May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Request]: Feed MetaRepoForXyz Configs Back to Projects

by stepharo

Yes this is important we should think modularly. Le 10/5/15 18:45, Sean P. DeNigris a Ã©crit : > For example, Soup's config was updated to declare a stable version for 4.0. > It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was > confusing that loading from the config browser worked, but loading via > another config as a dependent project did not (since we use the canonical > repo in that use case). > > Specifically, I am asking that if we update a config, and it's not Pharo > xyz-specific (i.e. may break other platforms), that we commit back to the > canonical repo or notify the maintainer if we don't have repo access. This > policy would obviously be especially easy for any project owned by the Pharo > team. > > Thanks :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 11, 2015

[pharo-project/pharo-core] af46bf: 50042

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: af46bfa669e063f6291c29a1f930f438e2a0d26c https://github.com/pharo-project/pharo-core/commit/af46bfa669e063f6291c29a1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-11 (Mon, 11 May 2015) Changed paths: M Collections-Sequenceable.package/OrderedDictionary.class/instance/printing/printElementsOn_.st M Graphics-Primitives.package/Color.class/class/examples/wheel_.st M Graphics-Primitives.package/Color.class/class/examples/wheel_saturation_brightness_.st M Graphics-Primitives.package/Color.class/instance/groups of shades/darkShades_.st M Graphics-Primitives.package/Color.class/instance/groups of shades/lightShades_.st M Graphics-Primitives.package/Color.class/instance/groups of shades/mix_shades_.st M Morphic-Base.package/SelectionMorph.class/instance/geometry/extent_.st M Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script650.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script651.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50041.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50042.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50042 15510 Missed some part of the original 15199 https://pharo.fogbugz.com/f/cases/15510 15518 association is misspelled in OrderedDictionary>>printElementsOn: https://pharo.fogbugz.com/f/cases/15518 15509 SelectionMorph>>extent: broken https://pharo.fogbugz.com/f/cases/15509 15474 Some Color method comments refere to Color>>showColors: https://pharo.fogbugz.com/f/cases/15474 http://files.pharo.org/image/50/50042.zip

May 11, 2015

[pharo-project/pharo-core]

by GitHub

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

May 11, 2015

New Cog VMs available

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r3332/. CogVM binaries as per VMMaker.oscog-eem.1298/r3332 NewspeakVM: Thread lookup rule through from bytecodes to internalFindNewMethod:. Fix genInnerPrimitiveMirrorNewWithArg:. Class's hash was being accessed twice, reusing variable holding jump instruction. Fix primitiveClass and genPrimitiveClass for mirror case (arg count = 1). Also fix Newspeak primitive table to allow nargs > 0 for genPrimitiveClass. General: Fix a regression in externalInstVar:ofContext:. The head frame pointers must be written back if we're going to map a machince code pc to a bytecode pc in case of code reclamation. Add asserts to the stack page enumerators to check that the head frame pointers have been written back. Fix changeClass: for forwwarded receivers. Use macros for the oop comparisons, avoiding cCoerce:, to get faster simulation and avoid the inliner not inlining in conditionals. Spur: Change computeRefCountToShrinkRT to - compute the ref counts and population in a single pass over the RT - determine the ref count for tenuring based on half the population of remembered objects, /not/ half the size of the RT. -- best, Eliot

May 11, 2015

Re: [Pharo-dev] Pending OS-X Cocoa Squeak VM build

by John McIntosh

Earlier today I pushed some updates to the Cog branch to enable you to compile the SqueakPureObjcCog found in build.macos64x64/squeak.stack.spur/ Right now it seems to be confused by "DateAndTime milliSecondsSinceMidnight" and hangs there. So just tap cmd-'.' to nuke the first call and show the screen. If someone can compile it and figure out what is broken that would be helpful. At the moment the other helper here is running a toolset a decade old and that won't compile the source, You need a current xCode or at least one that is 10.7 or better. On Thu, May 7, 2015 at 11:42 AM, John McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Morning. > > I've taken some time to integrate various Pharo and Pyonkee changes into > the Squeak OS-X and iOS cocoa source tree, along with converting the code > base to ARC and modern Obj-C. > > Earlier today I ran a Squeak4.5-13680 32bit image on a 64bit client > 3488 run, 3421 passes, 23 expected failures, 43 failures, 0 errors, 1 > unexpected passes > > However I need some folks to step forward and validate the results, > document what might be broken, look for behaviour anomalies, and refine > exactly what plugins are needed in the base system. > > I also need someone to try this on a 32bit host with 32bit image, and with > a current 64bit image (which I don't have) on a 64bit host. > > Drop me a note and I"ll forward a link to a binary for testing. > > Shortly I will be integrating these changes into the Cog branch and create > an XCode project for building a 64/64 Cog/etc VM. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > https://www.linkedin.com/in/smalltalk > =========================================================================== > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> https://www.linkedin.com/in/smalltalk ===========================================================================

May 11, 2015

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3326. CogVM binaries as per VMMaker.oscog-eem.1297/r3326 NewspeakVM: Thread lookup rule through from bytecodes to internalFindNewMethod:. Fix genInnerPrimitiveMirrorNewWithArg:. Class's hash was being accessed twice, reusing variable holding jump instruction. Fix primitiveClass and genPrimitiveClass for mirror case (arg count = 1). Also fix Newspeak primitive table to allow nargs > 0 for genPrimitiveClass. General: Fix a regression in externalInstVar:ofContext:. The head frame pointers must be written back if we're going to map a machince code pc to a bytecode pc in case of code reclamation. Add asserts to the stack page enumerators to check that the head frame pointers have been written back. Use macros for the oop comparisons, avoiding cCoerce:, to get faster simulation and avoid the inliner not inlining in conditionals. Spur: Change computeRefCountToShrinkRT to - compute the ref counts and population in a single pass over the RT - determine the ref count for tenuring based on half the population of remembered objects, /not/ half the size of the RT. Sista: Remove the storeCheck in inlined pointer at:put: if the value stored is an unannotatable constant. Increased the opcode size heuristic in the SistaCogit. -- best, Eliot

May 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: GanttChartMorph openOn: aCollectionOfActivities ?

by Alexandre Bergel

You should load the latest Roassal. Alexandre > Le 9 mai 2015 Ã 19:06, H. Hirzel <hannes.hirzel(a)gmail.com> a Ã©crit : > > Thank you for the examples, Alexandre! > > I have Pharo 4.0 with Roassal 2.0 installed (AlexandreBergel.718) > > I paste the following into a 'Playground' window and 'do it'. > > b := RTTimeLine new. > > b addEntry: (RTTimeLineEntry new identifier: #WP1; start: 0; end: 5). > b addEntry: (RTTimeLineEntry new identifier: #WP2; start: 5; end: 8). > b addEntry: (RTTimeLineEntry new identifier: #WP3; start: 7; end: 10). > > b axisX numberOfLabels: 5. > b > > I get the error message that RTTimeLine is not known. > > What am I missing? > > --Hannes > > >> On 5/8/15, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi Hannes! >> >> Here is a first shoot paired-programmed with Juraj using Roassal: >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> b := RTTimeLine new. >> >> b addEntry: (RTTimeLineEntry new identifier: #WP1; start: 0; end: 5). >> b addEntry: (RTTimeLineEntry new identifier: #WP2; start: 5; end: 8). >> b addEntry: (RTTimeLineEntry new identifier: #WP3; start: 7; end: 10). >> >> b axisX numberOfLabels: 5. >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> >> >> Here some slightly more elaborated example: >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> âOne color per entry" >> | b d | >> b := RTTimeLine new. >> b addEntry: (RTTimeLineEntry new identifier: #c1; start: 0; end: 5). >> b addEntry: (RTTimeLineEntry new identifier: #c1; start: 6; end: 8). >> >> b addEntry: (RTTimeLineEntry new identifier: #c2; start: 0; end: 5). >> b addEntry: (RTTimeLineEntry new identifier: #c2; start: 8; end: 10). >> >> b addEntry: (RTTimeLineEntry new identifier: #c3; start: 0; end: 10). >> >> b addEntry: (RTTimeLineEntry new identifier: #c4; start: 5; end: 10). >> >> b addEntry: (RTTimeLineEntry new identifier: #c5; start: 5; end: 8). >> >> d := RTVerticalTickLineDecorator new. >> d shape line color: Color white. >> b addDecorator: d. >> b axisX >> numberOfLabels: 5; >> labelRotation: -45; >> labelConversion: [ :v | Date year: 2015 day: v ]. >> >> b shape color: (RTMultiLinearColorForIdentity new objects: b entries). >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> >> >> One color per timeline >> >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> | b | >> b := RTTimeLine new. >> b addEntry: (RTTimeLineEntry new identifier: #c1; start: 0; end: 5). >> b addEntry: (RTTimeLineEntry new identifier: #c1; start: 6; end: 8). >> >> b addEntry: (RTTimeLineEntry new identifier: #c2; start: 0; end: 5). >> b addEntry: (RTTimeLineEntry new identifier: #c2; start: 8; end: 10). >> >> b addEntry: (RTTimeLineEntry new identifier: #c3; start: 0; end: 10). >> >> b addEntry: (RTTimeLineEntry new identifier: #c4; start: 5; end: 10). >> >> b addEntry: (RTTimeLineEntry new identifier: #c5; start: 5; end: 8). >> >> d := RTVerticalTickLineDecorator new. >> d shape line color: Color white. >> b addDecorator: d. >> b axisX >> numberOfLabels: 5; >> labelRotation: -45; >> labelConversion: [ :v | Date year: 2015 day: v ]. >> >> b shape color: (RTMultiLinearColorForIdentity new command: #identifier; >> objects: #(c1 c2 c3 c4 c5)). >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> >> Age of some classes: >> -=-=-=-=-=-=-=-=-=-=-=-= >> | b | >> b := RTTimeLine new. >> b extent: 500 @ 500. >> ((RTShape withAllSubclasses sortedAs: #ageInDaysRounded) select: >> #hasMethods) >> do: [ :cls | >> e := RTTimeLineEntry new. >> e identifier: cls. >> e start: cls computeYoungestMethod ageInDays. >> e end: cls computeOldestMethod ageInDays. >> b addEntry: e ]. >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> >> >> All these examples are in the Roassal time line example menu. >> >> This is still an early version. Let us know how it goes! >> https://www.facebook.com/ObjectProfile/posts/840542572699008 >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On May 7, 2015, at 4:25 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> >>> Hello >>> >>> Has somebody done a GANTT chart? >>> >>> GanttChartMorph openOn: aCollectionOfActivities >>> >>> ? >>> >>> Activities have >>> - id >>> - description >>> - start date >>> - end date >>> ? >>> >>> Regards >>> >>> Hannes > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

May 10, 2015

Re: [Pharo-dev] Error on loading GToolkit configuration

by Nicolai Hess

Thank you! 2015-05-10 12:44 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Made a small mistake in the configuration. > Should work now. > > Cheers, > Andrei > > On Sun, May 10, 2015 at 11:50 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> 15470 <https://pharo.fogbugz.com/default.asp?15470> >> Replace Announcer>>#on:send:to:'s senders in GTSpotter >> >> >> Pharo5.0 >> Latest update: #50040 >> >> >> Anyone knows why this fails: >> >> Gofer new >> smalltalkhubUser: 'Moose' project: 'GToolkit'; >> load; >> configurationOf: 'GTSpotter'; >> loadVersion:'1.2.4' >> -> Could not resolve: GT-SpotterExtensions-Core [ >> GT-SpotterExtensions-Core-AndreiChis.145] >> >> >

May 10, 2015

Re: [Pharo-dev] A fast Transcript

by J. Vuletich (mail lists)

Hi Eliot, Today I woke up with a simple idea: In Cuis' Transcript, once you do "Workspace with contents", keep a reference to that workspace, and add new Transcript stuff to it. This is done afterwards, when Morphic runs again. Immediate Transcript update is not affected. The effect is like having an editable Transcript, with a fast, immediate "preview" in a separate window. I just did a commit to the Cuis Github repo with this (amongst a lot of other changes). Please try it and tell if this simple solution is enough for your needs. OT: BTW, I added a new VMMaker package. It is a verbatim copy of the latest VMMaker in http://source.squeak.org/VMMaker/ . I didn't change a single line of code (except for one method in GeniePlugin that seems to break some compiler limit). It can generate all the plugins. This is all I tested so far. The GUI is not functional, due to the differences in Morphic. But at least there are no Undeclared. Cheers, Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Juan, > > I see that your new transcript is indeed much faster but is also not > editable. I wonder if it would be possible to have the best of both worlds > and arrange that, when active, the transcript is editable. For example, > selecting the TranscriptWIndow could put it into a mode where the > transcript's state was imported into a more conventional editable text > morph, and then when the window was exited, reverted to the standard fast > output mode. As you can infer I like having an editable transcript. I can > do without it, because Squeak's slow transcript is indeed a PITA, but I'm > not sure that speed need preclude editability. > > On Sat, May 9, 2015 at 10:17 AM, J. Vuletich (mail lists) < > juanlists(a)jvuletich.org> wrote: > >> Hi Folks, >> >> (below) >> >> >> Quoting Ben Coman <btc(a)openinworld.com>: >> >> On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >>> wrote: >>> >>> >>>> >>>> On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> From my limited experience bug hunting, calling #changed: from a thread >>>>> other than the UI thread is a source of evil. There are too many >>>>> assumptions throughout the system that the UI is single threaded. Can >>>>> anyone advise me that is not a proper belief? >>>>> >>>>> Then that implies that a Transcript implementation where #nextPut: >>>>> direct >>>>> calls #changed: >>>>> is not appropriate for use with multi-threaded applications. In Pharo, >>>>> #changed: is only called from #stepGlobal, which is called from >>>>> doOneCycle:. (This came about as a last minute bug fix before Pharo 3 >>>>> release and maybe could use some cleanup. >>>>> >>>>> Separating the UI from Transcript into its own viewer might be a good >>>>> idea, but actually it would not solve Stef's case since his code would >>>>> still be running in the UI thread -- unless the viewer ran in another >>>>> thread, which would have its own complexities. >>>>> >>>>> I think the point about efficiency is significant. The following >>>>> example... >>>>> Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' >>>>> ] ] >>>>> on Squeak 4.5 --> 12749ms >>>>> on Pharo 50029 --> 2ms >>>>> >>>>> This better performance helped me a lot trying to understand the high >>>>> priority timerEventLoop being able to indiscriminately scatter >>>>> Transcript >>>>> tracing through that code. I believe its also probably beneficial for >>>>> working with externally triggered semaphores and timing sensitive race >>>>> conditions. >>>>> >>>>> So we have two mutually exclusive cases: >>>>> * better interactivity, poorer system performance >>>>> * faster system performance, worse interactivity >>>>> >>>>> Which of these is broken depends on your viewpoint. >>>>> >>>>> >>>> Something that runs fast but is incorrect is still incorrect. The fact >>>> that the transcript doesn't output until a world step is possible is a >>>> bug. It forces programs that use the transcript to be rewritten in order >>>> to see transcript output. >>>> >>>> >>> As a point of comparison for correctness, for the following... >>> >>> Transcript clear. >>> [ $a asciiValue to: $z asciiValue do: [ :c | >>> [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i >>> printString , ' ' ] ] forkAt: 40 >>> ]. >>> ] forkAt: 41 >>> >>> Squeak 4.5 gives... >>> $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 >>> $c4 >>> $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 >>> $h2 >>> $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 >>> $b7 >>> $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 >>> $u3 >>> $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 >>> $o4 >>> $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 >>> $m5 >>> $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 >>> $k6 >>> $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 >>> $l7 >>> $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 >>> $h8 >>> $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 >>> $f9 >>> $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 >>> $u9 >>> $u9 $z9 $x9 >>> >>> Pharo 50041 gives... >>> $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 >>> $c1 >>> $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 >>> $e2 >>> $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 >>> $g3 >>> $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 >>> $i4 >>> $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 >>> $k5 >>> $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 >>> $m6 >>> $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 >>> $o7 >>> $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 >>> $q8 >>> $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 >>> $s9 >>> $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 >>> $v1 >>> $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 >>> $x2 >>> $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 >>> $z3 >>> $z4 $z5 $z6 $z7 $z8 $z9 >>> >>> (start your comparison at $b5) >>> >>> So in one axis Pharo has improved Transcript, but we didn't notice the >>> significance of the use case we lost. >>> >>> cheers -ben >>> >> >> Please take a good look at Cuis' Transcript and consider using it. >> >> By default, the display is updated immediately, but without calling >> Morphic, it can even work with no UI framework at all. It does updates >> faster than Squeak or Visualworks: >> >> Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: >> 'x' ] ]. 763. >> >> But if you want minimum overhead without immediate feedback: >> >> Time millisecondsToRun: [ Transcript showOnDisplay: false. 1000 >> timesRepeat: [ Transcript show: 'x' ]. Transcript showOnDisplay: true ]. 1. >> "As fast as Pharo" >> >> It is also thread safe, and for Ben's example: >> >> Transcript clear. >> [ >> $a asciiValue to: $z asciiValue do: [ :c | >> [ 1 to: 9 do: [ :i | Transcript show: c asCharacter >> printString , i printString , ' ' ] ] forkAt: 40 >> ]. >> ] forkAt: 41 >> >> it gives the same result as Pharo. >> >> The fact that the updates are not bound to Morphic also means that it is >> possible to do #show: deep in Morphic logic, without causing infinite loops >> or recursions, and get immediate feedback. It has proved to be a useful aid >> in debugging Morphic code. >> >> Cheers, >> Juan Vuletich >> >> >> > > > -- > best, > Eliot

May 10, 2015

Re: [Pharo-dev] [Request]: Feed MetaRepoForXyz Configs Back to Projects

by Sven Van Caekenberghe

It seems very logical to require configs to be save into there own repos. The other locations should just be copies. > On 10 May 2015, at 18:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > For example, Soup's config was updated to declare a stable version for 4.0. > It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was > confusing that loading from the config browser worked, but loading via > another config as a dependent project did not (since we use the canonical > repo in that use case). > > Specifically, I am asking that if we update a config, and it's not Pharo > xyz-specific (i.e. may break other platforms), that we commit back to the > canonical repo or notify the maintainer if we don't have repo access. This > policy would obviously be especially easy for any project owned by the Pharo > team. > > Thanks :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 10, 2015