January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Contributing to Pharo

by Eliot Miranda

Hi David, > On Jan 29, 2016, at 2:45 PM, David Allouche <david(a)allouche.net> wrote: > > Thanks Dale for all the explanations. > > How Monticello and version control relate in the big picture is starting to make sense for me. > > Now, I better understand why filetree ended up uses a file-per-method format, even though that is relatively hostile to git user interfaces optimised for other languages. There is really a need for a file-per-class exchange format, because that would works a lot better with the existing VCS ecosystem. I agree so strongly. Class file outs which are eg sorted by selector make much more sense. They won't hit the file name length limit. They make it trivial to maintain method and class comment time stamps. They're easier to construct into snapshots because it's easier to decode the file name. And then it's easy to add files for package load/unload scripts and for the history. And then one is much more decoupled from the specific back end. It could be mercurial just as easily as git. > I think more package-based user interfaces would indeed be a very good idea, for browsing and for source code management. > > Stef, I have the impression you think that git is popular because it is a new shiny toy. I disagree with this idea. Git is a typical worse-is-better tool. It's good enough for most people, but it still has many shortcomings. It is popular in spite of its shortcomings. It became popular as destination for projects shifting from CVS and Subversion. So it is unlikely to be displaced by a newer, incrementally shinier tools. Anything that will displace it will have to provide an improvement of a similar magnitude as the jump between centralised and distributed version control. This is a good analysis. What's valuable to the Pharo community is not displacing an already functional dvcs (Monticello) with an ill-suited one (git), but in being able to function in ecosystems like github where people can display their identity and where infrastructure for bug reports etc exist. > Still, I think it's a good idea not to restrict high level models to what git provides if that's a less than ideal fit to the image model. Absolutely. Dale's talk of ditching Monticello metadata fills me with repulsion and makes me want to ask is he trying to sabotage or what? It seems entirely destructive. We have a functional package manager which currently supports interchange between Pharo, Squeak and Cuis, something that I think is very important and valuable. We should have the confidence to improve on it and work on exchanging improvements between the dialects. For example Bert Freudenburg recently extended the commit dialog with the ability to mark changes to ignore, which are then /not/ committed, which makes it possible to maintain a few of one's favorite image mods without the tedium of reverting them (or whatever other Sisyphean means) to commit from ones work image. > I have a lot of ideas to improve browsing and source code management in Pharo. I can make no promises, but I would like to produce something there. Good luck in your efforts. _,,,^..^,,,_ (phone) Best, Eliot

Jan. 30, 2016

GTDebugger feedback - Setup/TearDown tabs for test cases

by Ben Coman

I really like the SetUp/TearDown tabs when debugging a failed test, however it seems a waste to devote a whole half of window to them causing lines in the Source tab to wrap unnecessarily. Could they be moved adjacent to the Source tab? I guess the Browse button would equally apply to #setUp and #tearDown methods. Also, you can edit the SetUp code but changes don't seem to be saved through. So can this either be fixed (including when the method doesn't exist) or there be some hint it can't be saved: * tab says [SetUp (read-only)] * in an fake comment above its code put "This method is read only" (maybe in light grey) * Instead of the yellow/orange "modified" triangle appearing in the top-right of the pane, make it another colour - maybe black to mean you can't save - I think red is reserved for meaning the pane was edited elsewhere? cheers -ben P.S. I'd like to add my voice to those commenting that the stepping buttons are too far away. Glancing back and forth between them and the code I feel like I'm watching a tennis game. P.P.S The icons on those buttons are real nice.

Jan. 30, 2016

Re: [Pharo-dev] Use cases for methods with optional parameters

by Damien Pollet

On 23 January 2016 at 16:12, stepharo <stepharo(a)free.fr> wrote: > If you have >> mother1 := foo:(bar:zork:fork) >> mother2 := foo:bar:(zork:bork:) >> > I'm not sure that this is allows in the same class. We should check that > in Python or ruby. > In Ruby: def m(x=42, y=51) â calling m(3) gets x=3, y=51 (the given arguments are passed into the leftmost parameters first) def m(options) â calling m( { x: 3, y: 4 } ) or m( x: 3, y: 4 ) gets options = { x: 3, y: 4 } So, a dictionary magically created because you passed something that either was already a dictionary, or used the syntax of dictionary key/value pairs. If you need default values for known keys, you take a default dictionary and override its contents using http://www.rubydoc.info/stdlib/core/Hash%3Aupdate In Python I think it's more like the first Ruby alternative, except arguments can be named (so those bypass the left-to-right assignment order) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 30, 2016

Re: [Pharo-dev] Contributing to Pharo

by David Allouche

Thanks Dale for all the explanations. How Monticello and version control relate in the big picture is starting to make sense for me. Now, I better understand why filetree ended up uses a file-per-method format, even though that is relatively hostile to git user interfaces optimised for other languages. There is really a need for a file-per-class exchange format, because that would works a lot better with the existing VCS ecosystem. I think more package-based user interfaces would indeed be a very good idea, for browsing and for source code management. Stef, I have the impression you think that git is popular because it is a new shiny toy. I disagree with this idea. Git is a typical worse-is-better tool. It's good enough for most people, but it still has many shortcomings. It is popular in spite of its shortcomings. It became popular as destination for projects shifting from CVS and Subversion. So it is unlikely to be displaced by a newer, incrementally shinier tools. Anything that will displace it will have to provide an improvement of a similar magnitude as the jump between centralised and distributed version control. Still, I think it's a good idea not to restrict high level models to what git provides if that's a less than ideal fit to the image model. I have a lot of ideas to improve browsing and source code management in Pharo. I can make no promises, but I would like to produce something there.

Jan. 29, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 075ec6: 50550

by Cyril Ferlicot Delbecque

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/01/2016 16:07, GitHub wrote: > Branch: refs/heads/5.0 Home: > https://github.com/pharo-project/pharo-core Commit: > 075ec66df6ea08e7be71d5275b08ca095432aa2b > https://github.com/pharo-project/pharo-core/commit/075ec66df6ea08e7be7 1d5275b08ca095432aa2b > > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-01-27 (Wed, 27 Jan 2016) > > Changed paths: M Alien.package/Alien.class/class/class > initialization/ensureInSpecialObjectsArray.st M > Alien.package/Alien.class/class/class initialization/initialize.st > M Alien.package/Alien.class/class/examples/libcName.st M > Alien.package/Alien.class/class/instance creation/atAddress_.st M > Alien.package/Alien.class/class/instance > creation/atAddress_dataSize_.st M > Alien.package/Alien.class/class/instance creation/forPointer_.st M > Alien.package/Alien.class/class/instance creation/newC_.st M > Alien.package/Alien.class/class/instance creation/newGC_.st M > Alien.package/Alien.class/class/instance creation/new_.st M > Alien.package/Alien.class/class/instance creation/rawNewC_.st M > Alien.package/Alien.class/class/system startup/startUp_.st M > Alien.package/Alien.class/definition.st R > Alien.package/Alien.class/instance/as yet > unclassified/isPointer.st M > Alien.package/Alien.class/instance/printing/storeOn_.st A > Alien.package/Alien.class/instance/testing/isPointer.st M > Alien.package/AlienSunit.class/instance/testing/testLongLong.st R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/README.md R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/accessing/pr oject.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/catalog/catalo gContactInfo.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/catalog/cata logDescription.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/catalog/catalo gKeywords.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/loading/load .st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/metacello tool support/isMetacelloConfig.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/metacello > tool support/lastMetacelloVersionLoad.st R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/metacello > tool support/metacelloVersion_loads_.st R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/private/boot strapPackage_from_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/private/ensure Metacello.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/definition.st R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/accessing /project.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines/b aseline10_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines /baseline12_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines/b aseline13_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines /baseline14_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines/b aseline15_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/doits/ffi ExampleInitialization10.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/symbolic versions/development_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/symbolic > versions/stable_.st R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version1%5F10%5F1_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve rsion1%5F10_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version1%5F9%5F1_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve rsion10_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version11_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve rsion12_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version13_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve rsion14_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version15_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve rsion16_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version17_.st > > R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve rsion18_.st > R > ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ version19_.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/README.m d > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/ac cessing/project.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/cata log/catalogContactInfo.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/ca talog/catalogDescription.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/cata log/catalogKeywords.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/de velopment > support/DevelopmentSupport.st R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/de velopment > support/validate.st R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/lo ading/load.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/load ing/loadBleedingEdge.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/lo ading/loadDevelopment.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/meta cello tool support/isMetacelloConfig.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/pr ivate/baseConfigurationClassIfAbsent_.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/priv ate/ensureMetacello.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/pr ivate/ensureMetacelloBaseConfiguration.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/definition .st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/instance /accessing/project.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/instance/b aselines/baseline10_.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/instance /symbolic > versions/stable_.st R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/instance /versions/version1%5F2_.st > > R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/instance/v ersions/version10_.st > R > ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/instance /versions/version11_.st > > A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instan ce/baselines/baseline0%5F11_.st > M > ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/inst ance/symbolic > versions/development_.st M > ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/inst ance/symbolic > versions/stable_.st A > ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/inst ance/versions/v0%5F11%5F2_.st > > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50549.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - > scripts/script50550.st R > ScriptLoader50.package/ScriptLoader.class/instance/pharo - > updates/update50549.st A > ScriptLoader50.package/ScriptLoader.class/instance/pharo - > updates/update50550.st M > ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCu rrentUpdate.st > > Log Message: ----------- 50550 17482 load UnifiedFFI 0.11.2 > https://pharo.fogbugz.com/f/cases/17482 > > 17479 Interval class comment mixes step/stop when explaining > Instance Variables https://pharo.fogbugz.com/f/cases/17479 > > http://files.pharo.org/image/50/50550.zip > > I do not see the change in interval doc in #50559 :( - -- Cyril -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWq9VpAAoJEBzpUtxBqUID4gUP/iUJV/2UxThAyNEkHbvfvNce 7+JlxNOFIQ3w9UzGayWRaK1FdwAf+2DL0h++Qr9E9zxfPzLpI2wFnYYe8sJjX9kj vrxV2TxcY883Jiu5T7FgXSy6YlUfjnoffY0RQbYSbb6vTkIbtWYTVTImqk9fLrLR 1LhhoAR6VjY8un+3IuEPyoFQcUn5//BcvYuyb1XVtvVlbAYfHwR3Lku77/nC3HtN JQP2LAqQkrTN33/9ofy39YU17VX5BztjtP0C4huVIbF8pBroHXqKVVCYd84D/oPb YGGreUo18Gb8RODg1WlmRpb317nWDQVOHgr6QAJEo27RFAgf6pSwdjtYNMMmtup1 dRBYwUIFXaALP+SG5MZxp7dOJ3ZL/oTu8EIcNE9wI75uuEEt0q3Y5uhhhxQqv5dT 041Vu6sIzqLC5ZUdBt3kuL2vKOTKX9HfkcCXYN7ND56vAPsu+Yp4ky6GcEuEhiOl 3NtXjsMeyifzRJVt/LWnYL5vWUC7zbxn7DMRLbV4f1qXvgEhfI7VFrWw0QyQADlW yI76CCME+eqj47HGC4zDJ33Xpiib+J6qVHOwPnzXR9kv8g4swFxbjHXdABTBbuzy WhS2sfNShOtX4Dm7zs6p157oARPQOnYOT3C1p5a89jmBXwuBPsWHHXAiwgMGfx+0 /IsT5/hHTqF8LjZ+FRSL =5vT7 -----END PGP SIGNATURE-----

Jan. 29, 2016

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

by serge.stinckwich＠gmail.com

For building Pharo, Squeak or GemStone projects on travis there is also the SmalltalkCI project: https://github.com/hpi-swa/smalltalkCI/blob/master/README.md Smalltalk language is supported by travis ;-) Sent from my iPhone > On 29 janv. 2016, at 18:28, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > 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 Dale Henrichs

On 01/29/2016 09:02 AM, Bernhard Pieber wrote: > 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, Very good question. You are absolutely correct, the act of writing a new version of a package using a different dialect would indeed destroy the platform-specific meta data. However, it is NOT expected that two different dialects (with different disk formats) share the same commit. If dialect A has committed a package, then dialect B is expected to be able to read the package written by dialect A. Being able to read the package means that all of the information that is common between the two dialects will be preserved ... in FileTree, this means that: - all of the class and instance method source is readable and shared - the method category is readable and shared - the name, superclass, instance variables, class instance variables, pools, class category, and class vars for classes is readable and shared This is an awful lot common data .... things like traits or namespaces are dialect specific and are ignored by dialects that don't have them when reading the package ... When dialect B has read, loaded/compiled and tested the code in the package, the developer has a couple of choices to be made when writing out a new package with her changes: - use the current branch - use a new branch I think that using a new branch is the cleanest option. When I port a project like Zinc[1] to GemStone[2], the master branch is preserved for the Pharo-specific code. I create a gs_master branch where the GemStone code goes. When Sven commits new code in his repo, I merge the changes from the his new master branch into my gs_master and resolve conflicts if any, run tests and I'm done. The vast mjority of the code base is shared between GemStone and Pharo and only the places where I made changes in porting Zinc to GemStone have the potential for conflicts. Running the tests should highlight any impacts not covered by direct conflicts and if there were some Pharo-specific meta data that I deleted on my branch that causes a test to fail then that is up to me to research and fix. When I have changes to feed back to Sven, I make those changes on a separate "topic branch"[3] that is merged into gs_master for my use. I then cherry-pick[4] the topic branch commit into a separate topic branch off of the master branch (this picks up only the changes I made on the topic branch) and open a pull request[5] against Svens repository ... if Sven were using travis-ci, tests would be run automatically against a merge of my changes into his master branch ... if the tests are green and the code passes Sven's scrutiny in a code review he merges my proposed changes into his master branch... GemStone and Pharo share a common disk format (not 100% common), but since git only merges the deltas for a commit, it is relatively easy to keep the meta data differences isolated while still sharing the vast bulk of the code and classes .... Dale [1] https://github.com/svenvc/zinc [2] https://github.com/GsDevKit/zinc [3] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows [4] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picki… [5] https://help.github.com/articles/using-pull-requests/

Jan. 29, 2016

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

by Esteban Lorenzano

Cobrale! Cobrale! ;) > On 29 Jan 2016, at 18:28, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > 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] 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