- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Mariano Martinez Peck

BTW, Esteban Maringolo asked me if the Travis scripts were "sharable". Well, Esteban Lorenzano shared them with me and I improved them a bit for my needs, so of course they are shareable! And all my projects listed as MIT, they are all MIT all the way down. Cheers, On Fri, Jan 29, 2016 at 3:36 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Nice ! > > > On 29 Jan 2016, at 01:03, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > Hi guys, > > > > This is just to let you know that with the help of Esteban and between > some work together [1] [2] I was able to have Travis CI integrated with > OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and > tested under Linux and OSX. Note also that one of the projects does a lot > of FFI calls to system libs like libc and the other even generates C > programs, compiles them and run it. Even the OS dependencies (like > installing the compiler) are resolved correctly :) > > > > If someone wants to know how it's done, simply check the .travis.yml and > the scripts/run-test.sh of each project [5] [6]. > > > > [1] https://pharo.fogbugz.com/f/cases/17488 > > [2] https://pharo.fogbugz.com/f/cases/17490 > > [3] https://travis-ci.org/marianopeck/OSSubprocess > > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor > > [5] https://github.com/marianopeck/OSSubprocess > > [6] https://github.com/marianopeck/FFICHeaderExtractor > > > > > > Cheers, > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Jan. 29, 2016

Re: [Pharo-dev] Contributing to Pharo

by Bernhard Pieber

Hi Dale, I am trying to understand this a little better. If a package containing metadata would be changed using a dialect which cannot interpret the metadata, wouldnât or at least couldnât it be broken or lost afterwards for a dialect which tries to interpret the metadata? At least if my assumption is correct that the metadata is related to the code in some way? Bernhard > Am 28.01.2016 um 21:28 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > On 01/28/2016 12:55 AM, Christophe Demarey wrote: >> Le 28 janv. 2016 Ã 09:34, Sven Van Caekenberghe a Ã©crit : >> By the way, we can add the storage format: there are already different versions of the filetree format (with metadata, without, one file per method, one file per class). At some point, we need to handle this point of variability. > On this point I think that we will always want to support multiple disk formats .... in a perfect world, there is no reason not to have one file per method and no Monticello meta data ... but perfection does not exist. > > Monticello meta data was included in FileTree because it was needed over the last 4 years so that developers could dip there toes into using git without completely abandoning Monticello .... Now that we are gaining a critical mass of users and the tool support is starting to show up, dropping the meta data is a practical thing to do ... but there is code committed on github that hasn't been updated in years that is still being used and Monticello meta data is still present, so it is necessary to "support the older formats". > > The one file per method was chosen for two reasons. > > The first reason has to do with the fact that disk based SCMs are designed manage files as atomic units and in Smalltalk the method is the atomic unit for source code ... it is very convenient to be able to leverage native SCN files for a) versioning files and b) maintaining version history for a method as it moves from class to class ... > > The second reason has to do with the fact that there is no cross platform fileout format for Smalltalk. Chunk format comes is "common" but chunk format also relies on executing Smalltalk code to define classes and there hasn't been a standard class creation method since the second Smalltalk implementation showed up on the planet ... Technically, class and method definitions can be derived from a file per class approach, but without a standardized file format you end up with each dialect isolating itself from the others and this is not desirable nor necessary ... It just takes more work to come up with a file format that can accommodate the different needs of the different dialects .... the one method per file and a generic properties file for class definitions[1] and the provision for allowing additional platform specific property files and directories (like monticello meta data) simplified the whole process ... > > So I would like changing the disk format for sharing source code to be a multi-platform effort - which means that format that is chosen is flexible enough to allow dialects to include the meta data that they need ... It is important to note that there has never been a guarantees that all platforms would PRESERVE and WRITE foreign meta data ... the only provision that exists is that ALL platforms can READ the format while ignoring anything it doesn't recognize .... > > Dale > > [1] https://raw.githubusercontent.com/CampSmalltalk/Cypress/master/img/CypressS…

Jan. 29, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 29, 2016

[pharo-project/pharo-core] 03f485: 50559

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 03f48517e360f34d4c97b75a5f3a77f32988a4de https://github.com/pharo-project/pharo-core/commit/03f48517e360f34d4c97b75a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-29 (Fri, 29 Jan 2016) Changed paths: R DebuggerActions.package/PeelToFirstDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/RestartDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/ResumeDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/ReturnValueDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/RunToSelectionDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/StepIntoDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/StepOverDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerActions.package/StepThroughDebugAction.class/instance/testing/appliesToDebugger_.st R DebuggerModel.package/DebugSession.class/instance/testing/isInterruptedContextPostMortem.st R GT-BytecodeDebugger.package/GTStepToBytecodeDebugAction.class/instance/testing/appliesToDebugger_.st R Glamour-Tests-Morphic.package/GLMMorphicExamplesTest.class/instance/tests/testSmoke.st M Nautilus.package/Nautilus.class/instance/accessing/selectedPackage_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50558.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50559.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50558.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50559.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50559 17489 remove testSmoke https://pharo.fogbugz.com/f/cases/17489 17463 NautilusUI>>#updatePackages MessageNotUnderstood: RPackage>>item https://pharo.fogbugz.com/f/cases/17463 17459 #isInterruptedContextPostMortem should not be used https://pharo.fogbugz.com/f/cases/17459 http://files.pharo.org/image/50/50559.zip

Jan. 29, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 29, 2016

[pharo-project/pharo-core] c99e24: 50558

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c99e24992162ba83eaacf95176c92ec9338c70c6 https://github.com/pharo-project/pharo-core/commit/c99e24992162ba83eaacf951… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-29 (Fri, 29 Jan 2016) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50557.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50558.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50557.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50558.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50558 16735 Replace Startup/Shutdown list with SessionManager https://pharo.fogbugz.com/f/cases/16735 http://files.pharo.org/image/50/50558.zip

Jan. 29, 2016

Re: [Pharo-dev] Color yzw

by Denis Kudriashov

And it is in 50556 2016-01-29 13:39 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-29 13:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hi Nicolai. >> Now your proposals in slice 17496 >> <https://pharo.fogbugz.com/f/cases/17496/add-table-for-all-defined-method-se…> >> . >> We change it a little bit: we make SelectorsTable lazy. And code >> completion uses it too. >> > > +1, > > Let's see if it works :) > Thanks > > > >> >> 2016-01-16 22:17 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> >>>> On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>>> >>>>> anyone an idea? >>>>> >>>>> I'm trying to think. >>>>> Looks like it would be good to be able to make a distinction between >>>>> symbols and selectors (selectors installed >>>>> in method dictionaries) >>>>> >>>>> >>>>> yes, this would improve code completion a bit, too, as there are more >>>>> symbols than symbols that are actually names >>>>> of methods. >>>>> >>>>> The data could be created per environment (Smalltalk globals) the >>>>> first time and then cached till shutdown. >>>>> (it would be an array of size 46451, pointing to existing symbols). >>>>> >>>>> The environment could cache sent selectors, tooâ¦ pablo did an >>>>> experiment with that. >>>>> >>>>> Marcus >>>>> >>>>> >>>> How about a new SymbolTable "SelectorTable" that gets new entries on >>>> every method compilation ? >>>> >>>> >>>> maybe better when a method is added to a Method Dictionary? This way >>>> even adding things the strange >>>> way would work... >>>> >>> >>> I tried some methods from TBehavior basicAddSelector:withMethod: >>> but for example Nautilus, directly modifies method dict >>> >>> >>>> >>>> >>>> I hacked a simple experimental version. >>>> But I don't yet understand the workflow for initialisation of the >>>> Symbol class (with rehash, interned, and compacting). >>>> >>>> >>>> If we hook into adding methods, then compactSymbolTable and rehash >>>> could just reset the SelectorTable and fill it after by going over all >>>> methodsâ¦ >>>> >>> >>> >>> see attached changesets. >>> >>> load with: >>> >>> DangerousClassNotifier disableDuring:[ >>> String subclass: #Symbol >>> instanceVariableNames: '' >>> classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable >>> SelectorTable' >>> package: 'Collections-Strings' >>> ]. >>> >>> DangerousClassNotifier disableDuring:[ >>> 'selectortable.1.cs' >>> asFileReference fileIn. >>> ]. >>> Symbol initSelectorTable. >>> 'use_selector_table.cs' asFileReference fileIn. >>> >>> what do you think ? >>> >>> (selectortable.cs defines SelectorTable and some methods in Symbol and >>> String) >>> (use_selector_table adds selectors as internedSelectorSymbol if this >>> selector is set as a selector on CompiledMethod >>> and uses findInternedSelector .... in RubStyler visitMessageNode) >>> >>> >>>> >>>> >>>> Marcus >>>> >>>> >>> >> >

Jan. 29, 2016

[pharo-project/pharo-core] 0def64: 50557

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0def643003d9b5298ee0a5c4f06a3e6f4f8daa18 https://github.com/pharo-project/pharo-core/commit/0def643003d9b5298ee0a5c4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-29 (Fri, 29 Jan 2016) Changed paths: M SUnit-UI.package/CommandLineTestRunner.class/instance/helper/printError_of_.st M SUnit-UI.package/CommandLineTestRunner.class/instance/helper/printFailure_of_.st A SUnit-UI.package/CommandLineTestRunner.class/instance/helper/shortStackDescriptionFor_.st M SUnit-UI.package/VTermTestRunner.class/instance/helper/print_short_of_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50556.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50557.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50556.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50557.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50557 17490 Command Line Handler test runner should print a small stack for failures and errors https://pharo.fogbugz.com/f/cases/17490 http://files.pharo.org/image/50/50557.zip

Jan. 29, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 29, 2016

Re: [Pharo-dev] Nitpick: Launcher Colors

by Sean P. DeNigris

CyrilFerlicot wrote > When the launcher is in full screen and the label of the image/template > is short, it allow to click on the right row where there is nothing. > In Windows it happen a lot that the window is in full screen. Got it! Thanks for the explanation. I retract my suggestion :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Nitpick-Launcher-Colors-tp4874592p4874719.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 29, 2016