April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Metacello configuration conventions

by Sean P. DeNigris

Dale Henrichs wrote > The Metacello Preview will support semantic versioning system! Cool! Thanks Dale :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682362… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by Nicolas Cellier

Sure, typical refactoring process. Code is convoluted and hard to follow, so you first document and explicit most obscure steps. In a second time, you realize how simpler it could be... Pharo is quite fast and still accelerating these days, so I understand the "satisfecit", it's already huge progress. My unsatisfied nature just tell to not stop in the middle of the bridge, and to not let un-necessarily complex code, even if well commented :) 2013/4/18 Marcus Denker <marcus.denker(a)inria.fr> > > On Apr 18, 2013, at 12:54 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > +1, the comments helps to understand, > > but this kind of stateful behavior sucks in the first place > > > > > It does, but one step at a time. > > Marcus > > >

April 18, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by Dale Henrichs

Martin, github pretty much requires a "master" branch, but it doesn't have to be named "master" ... For FileTree where I use the branch per platform approach, the master branch is where I stash the cherry-picked common code ... then all of the platform branches can merge at their leisure ... If you look at the network graph for FileTree[1] you can see the pattern. Dale [1] https://github.com/dalehenrich/filetree/network ----- Original Message ----- | From: mkobetic(a)gmail.com | To: "Frank Shearar" <frank.shearar(a)gmail.com> | Cc: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org>, "Pharo Development" | <Pharo-project(a)lists.gforge.inria.fr> | Sent: Thursday, April 18, 2013 7:14:34 AM | Subject: Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence | | As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just | experimenting with Cypress. However the master branch there is misleading, | it contains a very early port of Xtreams to ST/X (there's a much more up to | date version in Jan's ST/X project @ | https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/) | | However if you look at some of the other branches in the github project you | can find a fairly up to date, Cypress formatted dump from VW as well as the | results of Sean's ESUG effort to add namespace-prefix mapping to Filetree | (branch pharo_experiment). My ultimate goal is to test Dale's idea to | maintain a cross-dialect project as parallel branches in git. However we | still need to iron out various dialect differences in terms of what they | emit as Cypress formatted output. BTW, does anyone know if git/github can | handle absence of a master branch? I'd be inclined to just delete the master | from the repository if that works well. | | I've been planning to ping Sean about his Filetree fixes for a while, but I | need to find the time to be able to actually act on it :-). The | prefix-namespace mapping is crucial to make the parallel branch approach at | all feasible. There's also the Environment effort on Squeak side which may | obviate the prefix mapping need, but it seems to be still in fairly early | stages. | | So far it was mostly Nicolas' manual effort that brought VW updates over the | Squeak/Pharo side. I think it was a while since the last time he's done | that, so the VW port is probably ahead somewhat. But Xtreams development | isn't that active anymore. Most of our Xtreams related efforts are about | using them for various things, so any changes are mostly fixes or small | improvements driven by that use. So in some sense a manual update could be a | feasible approach at this point. But I would really like to turn the project | into a more collaborative effort, where updates can flow reasonably in any | direction. | | While I'm on the topic, I'm considering some API changes and am not sure how | to go about discussing it. I don't want to cross post discussions to a | number of mailing lists, so I think I'm inclined to just cross-post an | invitation to anyone interested to subscribe to the Issues on the project | site (https://code.google.com/p/xtreams/) and have those discussions there. | Any thoughts on that? | | "Frank Shearar"<frank.shearar(a)gmail.com> wrote: | > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely | > not the "canonical" repository, which would be in the Cincom Smalltalk | > Public Repository. I think? Anyway, assuming it's up to date, one | > promising approach to using Martin Kobetic's repository directly is: | > * have a way of importing chunk format stuff from a GitHub repository | > (see Squeak's inbox for my | > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub | > (and I plan to submit a Gofer patch to do the same)) | > * load into an Environment (Squeak 4.5 can do this, modulo its alpha | > state). | > | > It might even be possible to import into an Environment with the | > prefix-adding import and then fileout/monticelloise the resulting | > things as a prefix-using, non-Environments-requiring blob ready for | > everyone to use. | > | > frank | > | | |

April 18, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by mkobetic＠gmail.com

"Colin Putney"<colin(a)wiresong.com> wrote: > > While I'm on the topic, I'm considering some API changes and am not sure > > how to go about discussing it. I don't want to cross post discussions to a > > number of mailing lists, so I think I'm inclined to just cross-post an > > invitation to anyone interested to subscribe to the Issues on the project > > site (https://code.google.com/p/xtreams/) and have those discussions > > there. Any thoughts on that? > > > > That's probably the best approach: people interested in Xtreams ought > > to talk about Xtreams on the Xtreams list! > > > We may need a list eventually, but it would be kind of interesting to try > Martin's Issues approach. I guess we'd all subscribe to the Atom feed and > then "post" by opening or commenting on issues? It looks like anyone should be able to subscribe with arbitrary email address on the Issues section. Alternatively I could add people as project members if that helps. I'd like to use the Issues because that way any discussions are clearly associated and archived with the project.

April 18, 2013

Re: [Pharo-project] Metacello configuration conventions

by Dale Henrichs

----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 16, 2013 3:19:57 PM | Subject: Re: [Pharo-project] Metacello configuration conventions | | I liked ruby-gems approach more than the one in Metacello. You usually | specify | a major version (as under linux) for your dependency. That means the | dependency | might evolve a bit, typically for bugfixes, without you having to update | the configuration manually. | | http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see. | | As you say, #stable and #development are mostly for humans. Cami, I did look at the way ruby-gems worked pretty early on in Metacello development and I've arranged things such that I should be able to add the ability to specify ranges of versions, but the whole mechanics of the ruby-gem universe is different than the smalltalk universe so I'm not sure that Metacello would give you the behavior you are looking for even I did allow version ranges to be specified ... I'd be willing to spend time working through use cases with you to see if there would be benefit for enabling that feature... Dale

April 18, 2013

Re: [Pharo-project] Metacello configuration conventions

by Dale Henrichs

Sean, The Metacello Preview will support semantic versioning system as well as the current metacello versioning system ... and one will be able to choose on a project by project basis. I have all of the version comparison operators implemented for semantic versioning, but at the time I did the implementation there was some ambiguity about sort order for some of the version components (specifically related to pre-release and build versions), but I looked at the spec the other day and it seems that they seem to have clarified the wording ... which means I have to revisit my implementation:) Doesn't help with ensuring that developers increment the correct version component at the right time:) Dale ----- Original Message ----- | From: "Sean P. DeNigris" <sean(a)clipperadams.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 16, 2013 5:50:37 PM | Subject: Re: [Pharo-project] Metacello configuration conventions | | Camillo Bruni-3 wrote | > I liked ruby-gems approach more than the one in Metacello. You usually | > specify | > a major version (as under linux) for your dependency. | | It seems they're using semantic versioning, which is *awesome*, but can we | depend on the convention being followed? I've been pushing to get the tools | (e.g. Versionner) to use semantic version numbers by default (i.e. new | bugfix version, new enhancement version, new incompatible version) | | | | ----- | Cheers, | Sean | -- | View this message in context: | http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682036… | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | |

April 18, 2013

Re: [Pharo-project] files.pharo.org: Moving to new server

by Serge Stinckwich

Work like a charm. On Thu, Apr 18, 2013 at 10:43 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 18, 2013, at 3:01 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Hi, >> >> We will change the DNS to a new server. >> >> This should be transparent, but of course we never knowâ¦ >> >> Stages: >> >> 1) Change DNS to point to new server of (TODAY) >> files.pharo.org >> get.pharo.org >> updates.pharo.org >> > > Success! DNS has propagated (at least to here) and it works. > I should be more reliable and faster. > > Marcus -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 18, 2013

Re: [Pharo-project] files.pharo.org: Moving to new server

by Marcus Denker

On Apr 18, 2013, at 3:01 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We will change the DNS to a new server. > > This should be transparent, but of course we never knowâ¦ > > Stages: > > 1) Change DNS to point to new server of (TODAY) > files.pharo.org > get.pharo.org > updates.pharo.org > Success! DNS has propagated (at least to here) and it works. I should be more reliable and faster. Marcus

April 18, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by Frank Shearar

On 18 April 2013 15:14, <mkobetic(a)gmail.com> wrote: > As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just experimenting with Cypress. However the master branch there is misleading, it contains a very early port of Xtreams to ST/X (there's a much more up to date version in Jan's ST/X project @ https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/) > > However if you look at some of the other branches in the github project you can find a fairly up to date, Cypress formatted dump from VW as well as the results of Sean's ESUG effort to add namespace-prefix mapping to Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea to maintain a cross-dialect project as parallel branches in git. However we still need to iron out various dialect differences in terms of what they emit as Cypress formatted output. BTW, does anyone know if git/github can handle absence of a master branch? I'd be inclined to just delete the master from the repository if that works well. Github's fine with this. You have to choose a new default branch, and then you can freely git push origin :master. You can also recreate a new master, and reset default to it if desired. > I've been planning to ping Sean about his Filetree fixes for a while, but I need to find the time to be able to actually act on it :-). The prefix-namespace mapping is crucial to make the parallel branch approach at all feasible. There's also the Environment effort on Squeak side which may obviate the prefix mapping need, but it seems to be still in fairly early stages. Environments definitely needs more beating on it. We have flushed out a number of bugs, but in particular we need folks to just use it, and try out importing, nesting, and the like > So far it was mostly Nicolas' manual effort that brought VW updates over the Squeak/Pharo side. I think it was a while since the last time he's done that, so the VW port is probably ahead somewhat. But Xtreams development isn't that active anymore. Most of our Xtreams related efforts are about using them for various things, so any changes are mostly fixes or small improvements driven by that use. So in some sense a manual update could be a feasible approach at this point. But I would really like to turn the project into a more collaborative effort, where updates can flow reasonably in any direction. Agreed. In particular I'd like to push my #interleave: implementation upstream! I don't know how far out of sync things are, but certainly I don't feel any pain when using Xtreams. > While I'm on the topic, I'm considering some API changes and am not sure how to go about discussing it. I don't want to cross post discussions to a number of mailing lists, so I think I'm inclined to just cross-post an invitation to anyone interested to subscribe to the Issues on the project site (https://code.google.com/p/xtreams/) and have those discussions there. Any thoughts on that? That's probably the best approach: people interested in Xtreams ought to talk about Xtreams on the Xtreams list! frank > "Frank Shearar"<frank.shearar(a)gmail.com> wrote: >> How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely >> not the "canonical" repository, which would be in the Cincom Smalltalk >> Public Repository. I think? Anyway, assuming it's up to date, one >> promising approach to using Martin Kobetic's repository directly is: >> * have a way of importing chunk format stuff from a GitHub repository >> (see Squeak's inbox for my >> doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub >> (and I plan to submit a Gofer patch to do the same)) >> * load into an Environment (Squeak 4.5 can do this, modulo its alpha state). >> >> It might even be possible to import into an Environment with the >> prefix-adding import and then fileout/monticelloise the resulting >> things as a prefix-using, non-Environments-requiring blob ready for >> everyone to use. >> >> frank >> >

April 18, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by mkobetic＠gmail.com

As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just experimenting with Cypress. However the master branch there is misleading, it contains a very early port of Xtreams to ST/X (there's a much more up to date version in Jan's ST/X project @ https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/) However if you look at some of the other branches in the github project you can find a fairly up to date, Cypress formatted dump from VW as well as the results of Sean's ESUG effort to add namespace-prefix mapping to Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea to maintain a cross-dialect project as parallel branches in git. However we still need to iron out various dialect differences in terms of what they emit as Cypress formatted output. BTW, does anyone know if git/github can handle absence of a master branch? I'd be inclined to just delete the master from the repository if that works well. I've been planning to ping Sean about his Filetree fixes for a while, but I need to find the time to be able to actually act on it :-). The prefix-namespace mapping is crucial to make the parallel branch approach at all feasible. There's also the Environment effort on Squeak side which may obviate the prefix mapping need, but it seems to be still in fairly early stages. So far it was mostly Nicolas' manual effort that brought VW updates over the Squeak/Pharo side. I think it was a while since the last time he's done that, so the VW port is probably ahead somewhat. But Xtreams development isn't that active anymore. Most of our Xtreams related efforts are about using them for various things, so any changes are mostly fixes or small improvements driven by that use. So in some sense a manual update could be a feasible approach at this point. But I would really like to turn the project into a more collaborative effort, where updates can flow reasonably in any direction. While I'm on the topic, I'm considering some API changes and am not sure how to go about discussing it. I don't want to cross post discussions to a number of mailing lists, so I think I'm inclined to just cross-post an invitation to anyone interested to subscribe to the Issues on the project site (https://code.google.com/p/xtreams/) and have those discussions there. Any thoughts on that? "Frank Shearar"<frank.shearar(a)gmail.com> wrote: > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely > not the "canonical" repository, which would be in the Cincom Smalltalk > Public Repository. I think? Anyway, assuming it's up to date, one > promising approach to using Martin Kobetic's repository directly is: > * have a way of importing chunk format stuff from a GitHub repository > (see Squeak's inbox for my > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub > (and I plan to submit a Gofer patch to do the same)) > * load into an Environment (Squeak 4.5 can do this, modulo its alpha state). > > It might even be possible to import into an Environment with the > prefix-adding import and then fileout/monticelloise the resulting > things as a prefix-using, non-Environments-requiring blob ready for > everyone to use. > > frank >

April 18, 2013