Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello
That's going to make working out Metacello details a bit difficult:( Dale - Original Message - | From: Tudor Girba tu...@tudorgirba.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Thursday, July 25, 2013 1:08:30 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | snapshotcello | Unfortunately, I will not be able to join :( | Doru | On Wed, Jul 24, 2013 at 9:38 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Doru, | | | Are you going to be at ESUG this year? | | | I think there are some features of the Metacello Preview that can | | be | | of a great help to your Moose development and I think you and I | | need | | to spend time discussing the ins and outs in detail ... | | | I have also done a fair amount or work writing tools for tODE that | | manipulate sets of configurations using the MetacelloToolBox | | (Metacello Preview version), so perhaps your goal of automatic | | transitive versioning of all nested configurations is not as far | | away as you think. And again, I think some deep discussions at a | | whiteboard and some pair programming is probably the most | | efficient... | | | Dale | | | - Original Message - | | | | From: Tudor Girba tu...@tudorgirba.com | | | | To: Pharo Development List pharo-dev@lists.pharo.org | | | | Sent: Wednesday, July 24, 2013 11:24:20 AM | | | | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | | | snapshotcello | | | | | | | | Hi, | | | | | | | | On Jul 24, 2013, at 5:25 PM, Johan Brichau jo...@inceptive.be | | | | wrote: | | | | | | | | Doru, | | | | | | | | What do you understand with 'levels'? Is it referenced | | | projects? | | | | | | | | Yes. Nested projects, each being under development :) | | | | | | | | Perhaps this is the difference I did not immediately extract | | | from | | | | your description. Re-reading it with this focus makes the | | | | difference clear I think. | | | | | | | | My use of the toolbox is indeed to generate or update a version | | | for | | | | a single project where all 'nested' projects are referenced by | | | | project version. As I understand it, the snapshot version is a | | | | 'flattened' version containing all packages? | | | | | | | | Yes. | | | | | | | | My end goal would be to be able to create automatic transitive | | | | versioning of all nested configurations, but this requires some | | | more | | | | work, and likely some extension at the level of Metacello. So, | | | until | | | | this happens, we now have the option of snapshotting all | | | packages. | | | | | | | | The cool thing is that if you have something like: | | | | ConfigurationOfMoose depends on ConfigurationOfGlamour | | | | | | | | then in the list of snapshotted packages, you will also get the | | | | version of ConfigurationOfGlamour. Thus, essentially, you obtain | | | the | | | | same thing as if you would load nested configurations. | | | | | | | | The only problem is that because we lose configuration nesting | | | | information, Metacello is unable to resolve possible diamond | | | | conflicts. For example, suppose you have a project that depends | | | on | | | a | | | | certain version X of Glamour, but also would like to load the | | | whole | | | | Moose that loads version Y of Glamour. If you use normal | | | | configurations, Metacello should be able to detect the conflict, | | | but | | | | if you only have flattened versions, you will likely not detect | | | the | | | | conflict so easily. In any case, I think this is acceptable at | | | the | | | | moment. | | | | | | | | Cheers, | | | | Doru | | | | | | | | | | | | | | | | I think I get it now. thanks | | | | | | | | Johan | | | | | | | | On 24 Jul 2013, at 12:45, Tudor Girba tu...@tudorgirba.com | | | wrote: | | | | | | | | Perhaps I missed something in the toolbox, but as far as I | | | know | | | | you cannot create a version of a configuration that is | | | composed | | | | of multiple sub-projects nested multiple levels deep. | | | | | | | | Could you describe the way you are using the Metacello | | | Toolbox? | | | | | | | | Doru | | | | | | | | | | | | On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | | | | jo...@inceptive.be wrote: | | | | Hi Doru, Stef, | | | | | | | | May I ask what the difference is with the version generation | | | and | | | | updating methods found in MetacelloToolbox ? I want to | | | | understand, because I am currently using these of | | | | MetacelloToolbox to do the things you describe. | | | | | | | | Cheers! | | | | Johan | | | | | | | | On 24 Jul 2013, at 09:52, Stéphane Ducasse | | | | stephane.duca...@inria.fr wrote: | | | | | | | | | | | | On Jul 24, 2013, at 9:11 AM, Tudor Girba | | | tu...@tudorgirba.com | | | | | | | wrote: | | | | | | | | Hi, | | | | | | | | On Jul 24, 2013
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello
Stef, In Metacello there are more than one way to visit specs: - raw specs - merged specs - specs by section - resolved specs - there are more If you are reasoning about the packages visible for a particular combination of attributes (#common, #pharo, etc.) then you are interested in the 'merged specs'. If you are interested in looking at the individual statements that are composed into the merged specs, then you need to look at the raw specs, again against a particular combination of attributes. If you are editting a spec or interested in extracting the list of all packages referenced independent of attribute, then you need to look at the specs by section ... in which case you have the choice of looking at the raw specs or merged specs for each section visited. You also probably need to control whether or not imports are followed or not. If you are interested in knowing the exact package version and repository that a spec resolves to, then you need to look at resolved specs against a particular combination of attributes. So I guess I need to know a little bit more about what you are thinking when you say visitor on metacello spec. Dale - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, July 24, 2013 11:47:51 PM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re:[ann] snapshotcello | | Hi dale | | do you plan to write a visitor on metacello spec? | | Stef | | On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Doru, | | Are you going to be at ESUG this year? | | I think there are some features of the Metacello Preview that can | be of a great help to your Moose development and I think you and I | need to spend time discussing the ins and outs in detail ... | | I have also done a fair amount or work writing tools for tODE that | manipulate sets of configurations using the MetacelloToolBox | (Metacello Preview version), so perhaps your goal of automatic | transitive versioning of all nested configurations is not as far | away as you think. And again, I think some deep discussions at a | whiteboard and some pair programming is probably the most | efficient... | | Dale | | - Original Message - | | From: Tudor Girba tu...@tudorgirba.com | | To: Pharo Development List pharo-dev@lists.pharo.org | | Sent: Wednesday, July 24, 2013 11:24:20 AM | | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | | snapshotcello | | | | Hi, | | | | On Jul 24, 2013, at 5:25 PM, Johan Brichau jo...@inceptive.be | | wrote: | | | | Doru, | | | | What do you understand with 'levels'? Is it referenced | | projects? | | | | Yes. Nested projects, each being under development :) | | | | Perhaps this is the difference I did not immediately extract | | from | | your description. Re-reading it with this focus makes the | | difference clear I think. | | | | My use of the toolbox is indeed to generate or update a version | | for | | a single project where all 'nested' projects are referenced by | | project version. As I understand it, the snapshot version is a | | 'flattened' version containing all packages? | | | | Yes. | | | | My end goal would be to be able to create automatic transitive | | versioning of all nested configurations, but this requires some | | more | | work, and likely some extension at the level of Metacello. So, | | until | | this happens, we now have the option of snapshotting all | | packages. | | | | The cool thing is that if you have something like: | | ConfigurationOfMoose depends on ConfigurationOfGlamour | | | | then in the list of snapshotted packages, you will also get the | | version of ConfigurationOfGlamour. Thus, essentially, you obtain | | the | | same thing as if you would load nested configurations. | | | | The only problem is that because we lose configuration nesting | | information, Metacello is unable to resolve possible diamond | | conflicts. For example, suppose you have a project that depends | | on a | | certain version X of Glamour, but also would like to load the | | whole | | Moose that loads version Y of Glamour. If you use normal | | configurations, Metacello should be able to detect the conflict, | | but | | if you only have flattened versions, you will likely not detect | | the | | conflict so easily. In any case, I think this is acceptable at | | the | | moment. | | | | Cheers, | | Doru | | | | | | | | I think I get it now. thanks | | | | Johan | | | | On 24 Jul 2013, at 12:45, Tudor Girba tu...@tudorgirba.com | | wrote: | | | | Perhaps I missed something in the toolbox, but as far as I | | know | | you cannot create a version of a configuration that is | | composed | | of multiple sub-projects nested multiple levels deep
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: [ann] snapshotcello
- Original Message - | From: Tudor Girba tu...@tudorgirba.com | To: Any question about pharo is welcome pharo-us...@lists.pharo.org | Cc: Moose-related development moose-...@iam.unibe.ch, Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, July 24, 2013 12:07:48 AM | Subject: Re: [Pharo-users] [Moose-dev] Re: [ann] snapshotcello | | Hi, | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Stef, | | I haven't completely wrapped my brain around what SnapshotCello | does so I don't have an informed opinion ... the fact that you | found a need to invent SnapshotCello does speak volumes to the | fact that there is a need that is going unmet:). | | What is not clear? I would be interested in describing our scenario | in more details because I think this is a development pattern. But, | I need some concrete questions to start from. I do not completely understand what SnapshotCello is actually doing let alone why it is doing what it is doing ... So I need to spend time with it to wrap my brain around it then I can ask concrete questions | | However, I don't like the fact that you end up sending a non-spec | message to make this work (#populateSpec:with:). Tools like | Versioner will not be able to rewrite a method like this correctly | so it is a less than satisfactory workaround to the method literal | limit. | | I still do not understand why Versionner would be affected by the | current versions given that we are only generating versions that | should be immutable hence no need for management. I made my comments without having wrapped my head around SnapshotCello and it is my standard reaction to non-spec-based message sends ... I reserve the right to someday switch to a non-class-based implementation for Metacello and problems like too many literals in a method will no longer be a problem (and the tool many literals issue is but one of the forces driving me away from class-based specs), but specs that are generated dynamically based on data gleaned from arbitrary message sends will not be mappable. So I continue to repeat the message that Metacello does not support the dynamic generation of specs. In your particular case you are probably living within acceptable bounds, but the very existence of message sends within a spec may encourage other folks to try their hand at dynamic generationand we are off to the races:) So I continue to repeat the message that Metacello does not support the dynamic generation of specs. | | With that said it _is_ performing a useful function ... | | I have recently come up with an approach to addressing the method | literal limit from a slightly different angle and I would assume | that SnapshotCello could be recast to use this approved approach | when the new techinique becomes available. At that time it would | make sense to roll the SnapshotCello funtionality into the | MetacelloToolBox... | | Having a different way to store the information should be no problem. | I am curious about your ideas. I've tossed out some of my ideas in a post in the metacello mailing list[1]. And that would be a good place to discusss this further... Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tc4699965.html
Re: [Pharo-dev] Project Catalog getting out slowly :)
+1000 - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Saturday, July 13, 2013 5:13:40 AM | Subject: [Pharo-dev] Project Catalog getting out slowly :) | | Hi guys | | I start to be able to generate such files for a Pharo project catalog | | | | | I added some metadata to configuration files and it pays off. | | Stef
Re: [Pharo-dev] filetree jenkins job
Cami, I've been having trouble with getting any useful information from Pharo3.0 failures on travis-ci[1] for a week or so now ... Christophe will be looking into this for me... Dale [1] https://github.com/dalehenrich/filetree/issues/80#issuecomment-20162125 - Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: pharo-dev@lists.pharo.org | Sent: Sunday, July 7, 2013 2:00:10 PM | Subject: [Pharo-dev] filetree jenkins job | | after I tried to get filetree with the tests installed and I didn't | get it | the first time I decided to create a jenkins job. | | https://ci.inria.fr/pharo-contribution/job/FileTree/ | |
Re: [Pharo-dev] filetree jenkins job
Cami, Even worse, I don't get _any_ information about failures. When I run unit tests headless I get the following in my output: === Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st === === Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st === === Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st === === Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st === === Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st === === Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st === No stacks in the debug log, so I am completely blind when I run Pharo3.0 builds ... been happening about 2 weeks ... I assume there was a radical change to the way the Pharo3.0 reports headless errors, either by accident or on purpose... Christophe will be checking into this and I am sure he'll et me running again ... Until I can see what's happening with the builds I can't get the last little bits fixed for Pharo3.0 ... very close though:) Dale - Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Sunday, July 7, 2013 3:11:38 PM | Subject: Re: [Pharo-dev] filetree jenkins job | | I will change SUnit first produce proper error messages for the | #shouldnt:raise: methods since I cannot properly debug them. | Additionally at the point where the #:assert: happens the wrong | exception is not in the context which means it does not get properly | serialized by our test framework. All in all, with a little effort | we could debug much easier. | | BTW: There are so many strange methods on TAssertable that I do not | understand | - #shouldFix: | - #executeShould:inScopeOf: | | and some that I honestly think they hurt more than they help: | - #shouldnt:raise:whoseDescriptionIncludes:description: and friends? | | On 2013-07-07, at 23:47, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Cami, | | I've been having trouble with getting any useful information from | Pharo3.0 failures on travis-ci[1] for a week or so now ... | Christophe will be looking into this for me... | | Dale | | [1] | https://github.com/dalehenrich/filetree/issues/80#issuecomment-20162125 | - Original Message - | | From: Camillo Bruni camillobr...@gmail.com | | To: pharo-dev@lists.pharo.org | | Sent: Sunday, July 7, 2013 2:00:10 PM | | Subject: [Pharo-dev] filetree jenkins job | | | | after I tried to get filetree with the tests installed and I | | didn't | | get it | | the first time I decided to create a jenkins job. | | | | https://ci.inria.fr/pharo-contribution/job/FileTree/ | | | | | | | |
[Pharo-dev] Pharo2.0 unti test oddity
I'm running this test in Pharo2.0 using TestRunner. Can someone explain to me
why this test would PASS while:
- the debugger is not brought up
- the description of the exception _is_ displayed in the transcript
Error reading repository properties (.filetree):
/Users/dhenrich/Pharo2.0/Pharo2.0-portable.app/Contents/Resources/temp/repo ::
Error: end of input expected
Here's the test method:
testWrite
[
| packageName version versionInfo |
#('CCC') do: [ :pn | self deny: (self hasPackage: pn) ].
packageName := 'CCC'.
Gofer new
disablePackageCache;
repository: (self getTestRepository: 'issue33');
package: packageName;
load.
self validateTimestamp: 'dkh 11/2/1954 16:15'.
#('CCC')
do: [ :pn |
versionInfo := (MCWorkingCopy allManagers detect: [ :wc | wc
packageName = pn ]) ancestors first.
version := (self getTestRepository: 'issue33') versionWithInfo:
versionInfo.
(self getTestRepository: 'empty') storeVersion: version ]
]
on: Error
do:
[:ex |
self halt.
Transcript cr; show: ex description.
ex pass]
The test passes with flying colors if I run it from a workspace as well:
MCFileTreeIssue33Test debug: #testWrite
I'd kinda like to debug this test failure:(
Using Pharo2.0-20610 from Pharo2.0-portable download (in the last day or two).
Dale
Re: [Pharo-dev] filetree jenkins job
- Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Sunday, July 7, 2013 7:25:02 PM | Subject: Re: [Pharo-dev] filetree jenkins job | | | well that's what the fuel files are for... | | Can't you run the tests and copy the files to a safe location | | where | | you can analyze them offline? | | Nope. | | seems to be doable: | http://sleepycoders.blogspot.fr/2013/03/sharing-travis-ci-generated-files.html Like I said, I'm willing to be patient while Christophe supplies a solution to the problem... | | | | Depending on stack traces to debug is definitely history ;) | | I guess I won't be porting Metacello to Pharo3.0 then either... | | | Don't get me wrong, there still are stack traces, but most probably | the bug you experience is more hidden. In a local Pharo2.0 image, there are simply test failures and if I had a debug log of some sort, I would have fixed the problem 2 weeks ago:) My guess is that along with the changes that caused the debug log to disappear there were other changes related to running a headlesss remote vm in batch mode that I am ignorant of... | | What I am trying to say is that should use the fuel files to debug | failing tests instead of spending time deciphering dead text-based | stack traces. fuel files are not an option ... I'll tell you what though ... why don't you write come code that reads the fuel files into a pharo image and prints a stack trace to stdout ... that will get me exactly what I need and have for all of the other Smalltalk platforms ... When I am using travis, I am looking at the log file of the run just to see if the test passed or failed, so to have a dead stack trace right there in the log file that I am looking at is exactly what I WANT ... most of the time the stack trace is enough for me to debug the problem... | | And exactly in the case you describe theses fuel files can save you a | lot of time since you can basically debug the same way you debug a | local application. Except that I rarely write code in Pharo3.0, but I am interested in running tests and seeing the results of tests and seeing stack traces for failures for the code when it is run against Pharo3.0 ... These days I do the bulk of my development for FileTree, Metacello, etc. using tODE in GemStone, so I don't usually even have a Pharo development image (especially a fresh one) available to do testing ... so a stack trace actually saves me a whole lot of time... | | BTW: where do I see which tests fail under travis? clicking on the | status badges on the filetree page doesn't lead me to the direct | results. Here's the most recent pharo3.0 failure: https://travis-ci.org/dalehenrich/filetree/builds/8827089 I am actually merging code into the pharo3.0 branch even though I can't tell what's happening in the Pharo3.0 image ... the rest of the pharo, squeak and gemstone builds are all green so I expect that once Christophe has fixed the problem with Pharo3.0 I won't have a lot of work to do to get the tests passing ... Here's one from 18 days ago (the first one to go blind): https://travis-ci.org/dalehenrich/filetree/builds/8140902 Here's one from 22 days ago (the tests failed) which shows the logging information that used to work fine in Pharo3.0: https://travis-ci.org/dalehenrich/filetree/builds/8125607 | | In any case I see 4 failing tests on our jenkins build: | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=30,VERSION=stable,VM=vm/lastCompletedBuild/testReport/ | | are these the same you have on travis? | I haven't seen the test results from travis for 22 days, so I don't now what is going on with pharo3.0 ... keep in mind that Christophe and Thierry have been doing Pharo2.0 development and they are seeing tests pass in their local environent, but the totally opaque and useless error messages I'm getting on travis give me no clue as to what might be wrong up there ... 22 days ago I was getting adequate information from Pharo3.0 Dale
Re: [Pharo-dev] Pharo2.0 unti test oddity
And another better tidbit... the test that has the self halt is not related in
any way to the test that is causing the transcript error message to show up...
For some reason the error message (from a different test) shows up in the
transcript when I run the test that has the self halt in it ... I haven't
figured out why the messages to the Transcript are somehow deferred or why the
code that triggers the real error gets run while running a different test but
now that I have figured out that the apparent correlation between the test that
I was running and the message showing up in the transcript is bogus, I can get
on with tracking down the real problem in the test (that isn't failing), but
introducing the error into the system...
The test that introduces the error itself isn't failing, but it is creating a
repository that is generating the error, so the deferred message may be
triggered if the repo gets stuck in a cache somewhere that gets scanned while
running a different test --- at least that's my current hypothesis.
Sorry for the interruption:(
Dale
- Original Message -
| From: Dale K. Henrichs dale.henri...@gemtalksystems.com
| To: Pharo Development List pharo-dev@lists.pharo.org
| Sent: Sunday, July 7, 2013 9:16:39 PM
| Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity
|
| One more tidbit. This code brings up a debugger:
|
| testWrite
| self halt.
| [ | packageName version versionInfo |
| #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ].
| packageName := 'CCC'.
| Gofer new
| disablePackageCache;
| repository: (self getTestRepository: 'issue33');
| package: packageName;
| load.
| self validateTimestamp: 'dkh 11/2/1954 16:15'.
| #('CCC')
| do: [ :pn |
| versionInfo := (MCWorkingCopy allManagers detect: [ :wc |
| wc packageName = pn ]) ancestors first.
| version := (self getTestRepository: 'issue33')
| versionWithInfo: versionInfo.
| (self getTestRepository: 'empty') storeVersion: version
| ]] on:Error do:[:ex | self halt. Transcript cr; show: ex
| description. ex pass]
|
| So perhaps the issue I've seeing is related to a triggering a halt in
| an error handler ... Cami did your test trigger an error and print
| to the Transcript... I think that bad behavior is in the latest
| github checkin and the tests were passing until that checkin ...
|
| Dale
| - Original Message -
| | From: Dale K. Henrichs dale.henri...@gemtalksystems.com
| | To: Pharo Development List pharo-dev@lists.pharo.org
| | Sent: Sunday, July 7, 2013 9:11:46 PM
| | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity
| |
| | Cami,
| |
| | I thought maybe you'd tell me that I shouldn't be using halt or
| | that
| | the TestRunner is obsolete or something:)
| |
| | Actually I'm not surprised that you can find an image where that
| | code
| | works, the problem is that I've been able to hook up with an image
| | where it doesn't work:(
| |
| | Look, tests failed in travis so I downloaded the Pharo2.0-portable
| | (Pharo2.0-20610 and the timestamps on most of the files is July 3
| | at
| | 5:40 am ... the timestamps on the files in the Mac directory are
| | March 13 at 10:31am) and I'm running on a 10.6.8 Mac.
| |
| | I don't know how you've built your image, but the one that I'm
| | using
| | has loaded the latest code from the pharo2.0 branch on github
| | (71f4216bffee0e5a998ec903cb6ffb6d838db0ce) including Thierry
| | Goubier's git repository code, which brings in OsProcess ... as I
| | said I'm trying to locally reproduce test issues that showed up on
| | Travis ...
| |
| | ... and I've run out of time to monkey with this anymore this
| | evening:)
| |
| |
| | Dale
| |
| | - Original Message -
| | | From: Camillo Bruni camillobr...@gmail.com
| | | To: Pharo Development List pharo-dev@lists.pharo.org
| | | Sent: Sunday, July 7, 2013 7:57:47 PM
| | | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity
| | |
| | | It's hard to guess without an image...
| | | I took the one from here
| | |
https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=20,VERSION=stable,VM=vm/
| | | is that more or less the same as what you have?
| | |
| | | When I copy paste your code it works as expected and opens the
| | | debugger on halt.
| | | Which VM?
| | | Which OS?
| | |
| | | On 2013-07-08, at 04:35, Dale K. Henrichs
| | | dale.henri...@gemtalksystems.com wrote:
| | |
| | | I'm running this test in Pharo2.0 using TestRunner. Can someone
| | | explain to me why this test would PASS while:
| | |
| | | - the debugger is not brought up
| | | - the description of the exception _is_ displayed in the
| | | transcript
| | |
| | | Error reading repository properties (.filetree):
| | |
/Users/dhenrich/Pharo2.0/Pharo2.0-portable.app/Contents/Resources/temp/repo
| | | :: Error: end of input expected
Re: [Pharo-dev] Metacello doubt
Ah, at one point in time the tutorial was loaded by default ... sorry about that. to get the Metacello tutorial execute: ConfigurationOfMetacello project currentVersion load: 'Tutorial' Then you can find the Metacello documentation under the Help menu in the Help Browser ... Dale - Original Message - | From: p...@highoctane.be | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Friday, June 28, 2013 6:48:59 AM | Subject: Re: [Pharo-dev] Metacello doubt | I loaded ConfigurationOfProfStef but there is no MetacelloToolbox | documentation in there. | What do I miss? | Phil | --- | Philippe Back | Dramatic Performance Improvements | Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 | Mail:p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be | Twitter: @philippeback | Youtube: http://www.youtube.com/user/philippeback/videos | High Octane SPRL | rue cour Boisacq 101 | 1301 Bierges | Belgium | Featured on the Software Process and Measurement Cast | http://spamcast.libsyn.com | Sparx Systems Enterprise Architect and Ability Engineering EADocX | Value Added Reseller | On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Phil, | | | Check out the System Help ... the API is documented under | | MetacelloMetacelloToolBox ... under PrfStefBrowse | | tutorialsInside Metacello Toolbox there are 5-6 lessons there are | | other Metacello tutorials there as well ... | | | Dale | | | | From: p...@highoctane.be | | | | | | To: Pharo Development List pharo-dev@lists.pharo.org | | | | | | Sent: Wednesday, June 26, 2013 1:45:36 PM | | | | | | Subject: Re: [Pharo-dev] Metacello doubt | | | | | | While we are at it, is there any documentation for the | | | MetacelloToolbox? | | | | | | Couldn't find... Saw Sean's thing but nothing else. | | | | | | Would be great! | | | | | | TIA | | | | | | Phil | | | | | | --- | | | | | | Philippe Back | | | | | | Dramatic Performance Improvements | | | | | | Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 | | | | | | Mail:p...@highoctane.be | Web: http://philippeback.eu | | | | | | Blog: http://philippeback.be | Twitter: @philippeback | | | | | | Youtube: http://www.youtube.com/user/philippeback/videos | | | | | | High Octane SPRL | | | | | | rue cour Boisacq 101 | 1301 Bierges | Belgium | | | | | | Featured on the Software Process and Measurement Cast | | | | | | http://spamcast.libsyn.com | | | | | | Sparx Systems Enterprise Architect and Ability Engineering EADocX | | | Value Added Reseller | | | | | | On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs | | | dale.henri...@gemtalksystems.com wrote: | | | | | | | Guido, | | | | | | | | | | If the maintainer of a configuration would like to support | | | | bleeding | | | | edge loads that propagate through the dependent projects then | | | | they | | | | should specify which baseline version to use for each dependent | | | | project. For Native Boost the entry for AsmJit in the | | | | #baseline13: | | | | method could be changed to: | | | | | | | | | | project: 'AsmJit' | | | | | | | | | | with: [ | | | | | | | | | | spec | | | | | | | | | | className: 'ConfigurationOfAsmJit'; | | | | | | | | | | == versionString: #bleedingEdge; | | | | | | | | | | repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main | | | | ' | | | | ]; | | | | | | | | | | Then the bleedingEdge load would be propagated through to the | | | | dependents ... but then you'd want the AsmJit configuration | | | | modified | | | | as well:) | | | | | | | | | | Dale | | | | | | | | | | | From: Guido Chari cha...@gmail.com | | | | | | | | | | | | | | | To: pharo-dev@lists.pharo.org | | | | | | | | | | | | | | | Sent: Wednesday, June 26, 2013 7:27:19 AM | | | | | | | | | | | | | | | Subject: [Pharo-dev] Metacello doubt | | | | | | | | | | | | | | | I have a question since i'm trying to create some jenkins job | | | | | for | | | | | the | | | | | first time. Sorry if this was already discussed... | | | | | | | | | | | | | | | I have a dependency with for example NativeBoost. And i want | | | | | NativeBoost in its bleedingEdge version. If I | | | | | loadBleedingEdge | | | | | NativeBoost is on its last version on every package but not | | | | | its | | | | | own | | | | | dependencies as for example AsmJit. Is this the right | | | | | behavior? | | | | | How | | | | | can i express to have not only my dependency but also the | | | | | dependencies of my dependencies in its bleedingEdge version? | | | | | | | | | |
Re: [Pharo-dev] Metacello tutorial: ToolSet browse: ?!
I guess I have to rewrite my tutorials for pharo2.0, too:( I haven't quite finished porting Metacello to Pharo2.0... I suggest that you open a browser on the class MetacelloTutorialConfig and just manually select the methods ... Offhand I don't know what the new mechanism for 2.0 is... Dale - Original Message - | From: p...@highoctane.be | To: Discusses Development of Pharo pharo-dev@lists.pharo.org | Sent: Friday, June 28, 2013 7:06:34 AM | Subject: [Pharo-dev] Metacello tutorial: ToolSet browse: ?! | I guess that | ToolSet browse: MetacelloTutorialConfig selector: #version01:. | has been superseded by something else in Pharo 2.x + | What to use there? Has Nautilus something for that purpose? | Thx, | Phil
Re: [Pharo-dev] Metacello tutorial: ToolSet browse: ?!
Torsten, Does that work in Squeak? ... Metacello is not just for Pharo, so I do not have the freedom to leverage pharo-specific capabilities, nor do I have the cycles available to rewrite everything every 6 months ... I do accept contributions, so if you'd like to rewrite the tutorial in markup I'd be glad to include it in the pharo2.0 version of metacello when we finally get all of the functionality finished... Christophe has been very helpful in the port of Metacello to Pharo2.0 and we are very close to being able to release it ... we're just not there yet.. Dale - Original Message - | From: Torsten Bergmann asta...@gmx.de | To: pharo-dev@lists.pharo.org | Sent: Friday, June 28, 2013 8:31:52 AM | Subject: [Pharo-dev] Metacello tutorial: ToolSet browse: ?! | | I guess I have to rewrite my tutorials for pharo2.0 | | Easiest ist to write them in Markup and then use them in | Pharo Online Help | | Just open a fresh Pharo 2.0, open Tools - Config Browser | load Pharo Online Help and run the local webserver that | serves the tutorials | | Please try it - its much easier and more powerful than old help | | Have fun | Torsten | | |
Re: [Pharo-dev] Versions Browser over gitfiletree://
Yes, please. Dale - Original Message - | From: Goubier Thierry thierry.goub...@cea.fr | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Thursday, June 27, 2013 12:13:40 AM | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | Hi Dale, | | should I merge this work into the last pull request (#85) I made? | I've | corrected a few bugs and solved some performance issues, in addition | to | adding the API for querying and loading parts of a package. It's | currently on a separate branch. | | Thierry | | | Le 27/06/2013 01:26, Dale K. Henrichs a écrit : | Cool! I plan to integrate your work soon and I expect to merge your | work on the Pharo3.0 branch as well... | | Dale | | - Original Message - | | From: GOUBIER Thierry thierry.goub...@cea.fr | | To: Pharo Development List [pharo-dev@lists.pharo.org] | | pharo-dev@lists.pharo.org | | Sent: Wednesday, June 26, 2013 2:28:55 PM | | Subject: [Pharo-dev] Versions Browser over gitfiletree:// | | | | Or ... A first step towards Pharo without a changeset. | | | | Thierry | | | | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 | |
Re: [Pharo-dev] Versions Browser over gitfiletree://
Cami, Agreed ... the monticello meta data is only necessary for backward compatibility (being able to move packages back and forth between mcz repos and git repos) there's an almost infinite number of ways that the Monticello definitions can be cast in directory structure and I'm not sure that there is an optimal format:) as different formats yield different tradeoffs ... Dale - Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Thursday, June 27, 2013 12:32:13 AM | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | without Monticello file back-end no? | | No, in fact it's very much dependent on Monticello filetree back | end. This backend has the granularity which allow a use of git | querying / fetching facilities to the level associated with | changesets. | | I could implement a use of a gitfiletree:// repo as a complete | replacement of a live changeset + monticello repository in one, if | needed. | | Still wondering if this is the way to go. | | I think it is a very good start :), | eventually we have to come up with second version of the filetree | format as | the current one has a major limitiation: categories are stored in the | method source | | Impact: | - md5 hashes of the pure ST method sources do not correspond the md5 | hashes in the | git repository | - each file-in requires another strip-the-category-path | | of course there are workarounds for that. Additionally I would love | to have a | filetree version that doesn't store all this MC metadata. The changes | in these | files generate so much noise that is it hard to see the actual | changes. | | Anyway, most of it is future talk, I guess the current approach will | work :) | | Though I wonder what we will do once we have custom slots :/. I guess | we need | some hacks to make that run on top of Monticello. |
Re: [Pharo-dev] Metacello doubt
- Original Message - | From: Igor Stasenko siguc...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Thursday, June 27, 2013 4:26:14 AM | Subject: Re: [Pharo-dev] Metacello doubt | | Just adding some comments: | - i avoid using loading bleeding edge | because it has problems which only humans can solve: | - if there are two different branches, not yet merged it may load | not one that you want | - even if dependencies is ok, it doesn't means that if you load two | latest versions of two packages, | they will work | | so, what i do, is loading a known working config, and then go to | monticello and manually picking and loading updated packages. | But once the human has solved the problem, the solution should be encoded in a script that can be used by others to solve the same problem ... It's the manual bits that I'm trying to address with the Scripting API ... if you know you want to deviate from the standard load directives, you should be able to construct a load expression that allows you to specify your deviations so you can do your next build without requiring manual intervention... Dale
Re: [Pharo-dev] Versions Browser over gitfiletree://
Excellent! - Original Message - | From: Goubier Thierry thierry.goub...@cea.fr | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Thursday, June 27, 2013 7:08:40 AM | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | Done, | | Thierry | | Le 27/06/2013 15:25, Dale K. Henrichs a écrit : | Yes, please. | | Dale | | - Original Message - | | From: Goubier Thierry thierry.goub...@cea.fr | | To: Pharo Development List pharo-dev@lists.pharo.org | | Sent: Thursday, June 27, 2013 12:13:40 AM | | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | | | Hi Dale, | | | | should I merge this work into the last pull request (#85) I made? | | I've | | corrected a few bugs and solved some performance issues, in | | addition | | to | | adding the API for querying and loading parts of a package. It's | | currently on a separate branch. | | | | Thierry | | | | | | Le 27/06/2013 01:26, Dale K. Henrichs a écrit : | | Cool! I plan to integrate your work soon and I expect to merge | | your | | work on the Pharo3.0 branch as well... | | | | Dale | | | | - Original Message - | | | From: GOUBIER Thierry thierry.goub...@cea.fr | | | To: Pharo Development List [pharo-dev@lists.pharo.org] | | | pharo-dev@lists.pharo.org | | | Sent: Wednesday, June 26, 2013 2:28:55 PM | | | Subject: [Pharo-dev] Versions Browser over gitfiletree:// | | | | | | Or ... A first step towards Pharo without a changeset. | | | | | | Thierry | | | | | | | | -- | | Thierry Goubier | | CEA list | | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | | 91191 Gif sur Yvette Cedex | | France | | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 | | | | | | | | | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 | |
Re: [Pharo-dev] Metacello doubt
Allright ... I'll add a test case covering #bleedingEdge loads (perhaps not today...) and let you know if it's already functional or not ... if not I'll plan on getting it supported ... Dale - Original Message - | From: Guido Chari cha...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Thursday, June 27, 2013 10:23:33 AM | Subject: Re: [Pharo-dev] Metacello doubt | I'm in. | 2013/6/26 Dale K. Henrichs dale.henri...@gemtalksystems.com | | | From: Guido Chari cha...@gmail.com | | | | | | To: Pharo Development List pharo-dev@lists.pharo.org | | | | | | Sent: Wednesday, June 26, 2013 2:49:09 PM | | | | | | Subject: Re: [Pharo-dev] Metacello doubt | | | | | | I understood. Thanks for the answer Dale. The drawback in this | | | case | | | is to specify a particular dependency to AsmJit in my | | | configuration. | | | Also, perhaps is the right way since i realized i have a | | | particular | | | dependency on it. | | | | | | But this discussion makes me thing a little and so i have a new | | | question. | | | | | | Form what I (mis) undestand from Metacello, when asking for a | | | bleedingEdge version it loads only the baseline that specifies | | | packages and then last version of every package specified there. | | | | | | As in the projects referenced on the baseline there is no need | | | for | | | specifying a version, and that's the case of nativeBoost | | | configuration, wouldn't it be interesting to have some behavior | | | (i | | | mean i new method for loading like loadDeepSymbolic:) that not | | | only | | | load the symbolicVersion of the package asked, but also propagate | | | that symbolicVersion (bleedingEdge in this case) to all the | | | dependencies that don't specify a concrete version? | | | | | | Guido. | | | | | Guido, | | | With the Metacello Scripting API[1] I've taken a slightly different | | tack, but I think that it gets you to the same place. | | | I am a big fan of deterministic loads, but I know that from a | | practical point of view developers need to have a certain amount of | | control over exactly what gets loaded into their DEVELOPMENT | | environments and they need to be able to exert this control without | | having to resort to editing configurations to match their specific | | requirements. | | | I have accomplished this by arranging for a Notification to be | | signalled whenever a project is referenced during a load. The | | developer can use one or more of the onUpgrade:, onDowngrade: and | | onConflict: clauses in their load scripts to exert fine control | | over | | what happens on a project by project basis ... | | | For your specific use case, I would think that you would want to | | use | | the `lock` command[2] and specify that you want to `lock` the | | projects (NativeBoost and AsmJit) to the #bleedingEdge version. I | | don't recall if I've got test cases for symbolic versions, but if | | you are seriously interested in taking the Scripting API for a | | spin, | | I'd be willing to write some additional tests using the | | #bleedingEdge symbolic version (if not already covered) and | | validate | | this use case... | | | I am entering a phase where I will be doing some work on getting | | FileTree and Metacello up to snuff for Pharo3.0 so this would be a | | good time for me to add some test cases in anticipation of having | | some interested users ... | | | I haven't released the Scripting API, because I need to have real | | users with real use cases take the API for a spin and validate the | | API. The Scripting API can be loaded into any version of | | Pharo/Squeak/GemStone and I think the Scripting API is (or will be) | | available in Pharo3.0. | | | I'm looking forward to getting feedback as to how the API stands up | | to real use ... | | | So let me know if you are interested in being another Scripting API | | guinea pig:) | | | Dale | | | [1] | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md | | | [2] | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking |
Re: [Pharo-dev] Metacello doubt
Phil, Check out the System Help ... the API is documented under MetacelloMetacelloToolBox ... under PrfStefBrowse tutorialsInside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ... Dale - Original Message - | From: p...@highoctane.be | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, June 26, 2013 1:45:36 PM | Subject: Re: [Pharo-dev] Metacello doubt | While we are at it, is there any documentation for the | MetacelloToolbox? | Couldn't find... Saw Sean's thing but nothing else. | Would be great! | TIA | Phil | --- | Philippe Back | Dramatic Performance Improvements | Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 | Mail:p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be | Twitter: @philippeback | Youtube: http://www.youtube.com/user/philippeback/videos | High Octane SPRL | rue cour Boisacq 101 | 1301 Bierges | Belgium | Featured on the Software Process and Measurement Cast | http://spamcast.libsyn.com | Sparx Systems Enterprise Architect and Ability Engineering EADocX | Value Added Reseller | On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Guido, | | | If the maintainer of a configuration would like to support bleeding | | edge loads that propagate through the dependent projects then they | | should specify which baseline version to use for each dependent | | project. For Native Boost the entry for AsmJit in the #baseline13: | | method could be changed to: | | | project: 'AsmJit' | | | with: [ | | | spec | | | className: 'ConfigurationOfAsmJit'; | | | == versionString: #bleedingEdge; | | | repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main ' ]; | | | Then the bleedingEdge load would be propagated through to the | | dependents ... but then you'd want the AsmJit configuration | | modified | | as well:) | | | Dale | | | | From: Guido Chari cha...@gmail.com | | | | | | To: pharo-dev@lists.pharo.org | | | | | | Sent: Wednesday, June 26, 2013 7:27:19 AM | | | | | | Subject: [Pharo-dev] Metacello doubt | | | | | | I have a question since i'm trying to create some jenkins job for | | | the | | | first time. Sorry if this was already discussed... | | | | | | I have a dependency with for example NativeBoost. And i want | | | NativeBoost in its bleedingEdge version. If I loadBleedingEdge | | | NativeBoost is on its last version on every package but not its | | | own | | | dependencies as for example AsmJit. Is this the right behavior? | | | How | | | can i express to have not only my dependency but also the | | | dependencies of my dependencies in its bleedingEdge version? | | |
Re: [Pharo-dev] Metacello doubt
- Original Message - | From: Guido Chari cha...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, June 26, 2013 2:49:09 PM | Subject: Re: [Pharo-dev] Metacello doubt | I understood. Thanks for the answer Dale. The drawback in this case | is to specify a particular dependency to AsmJit in my configuration. | Also, perhaps is the right way since i realized i have a particular | dependency on it. | But this discussion makes me thing a little and so i have a new | question. | Form what I (mis) undestand from Metacello, when asking for a | bleedingEdge version it loads only the baseline that specifies | packages and then last version of every package specified there. | As in the projects referenced on the baseline there is no need for | specifying a version, and that's the case of nativeBoost | configuration, wouldn't it be interesting to have some behavior (i | mean i new method for loading like loadDeepSymbolic:) that not only | load the symbolicVersion of the package asked, but also propagate | that symbolicVersion (bleedingEdge in this case) to all the | dependencies that don't specify a concrete version? | Guido. Guido, With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place. I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements. I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ... For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case... I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ... I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0. I'm looking forward to getting feedback as to how the API stands up to real use ... So let me know if you are interested in being another Scripting API guinea pig:) Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking
Re: [Pharo-dev] Versions Browser over gitfiletree://
Cool! I plan to integrate your work soon and I expect to merge your work on the Pharo3.0 branch as well... Dale - Original Message - | From: GOUBIER Thierry thierry.goub...@cea.fr | To: Pharo Development List [pharo-dev@lists.pharo.org] pharo-dev@lists.pharo.org | Sent: Wednesday, June 26, 2013 2:28:55 PM | Subject: [Pharo-dev] Versions Browser over gitfiletree:// | | Or ... A first step towards Pharo without a changeset. | | Thierry
[Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
When I use the following url: http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz I get: /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found instead of my package downloaded ... the mcz file used to be there and it does show up in the listing for http://smalltalkhub.com/mc/dkh/metacello/main the repository ... In fact none of the packages in the metacello repository are accessible... Part of the site must down? Dale
Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
I can access the mcz file when I go to this url: http://smalltalkhub.com/#!/~dkh/metacello/versions/Metacello-ToolBox-dkh.131 and press the download button ... but trying to download the package to my image with: http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz gives me an the not found message. BTW, this was working not more than an hour ago... Dale - Original Message - | From: Dale K. Henrichs dale.henri...@gemtalksystems.com | To: pharo-dev@lists.pharo.org | Sent: Sunday, June 23, 2013 12:32:32 PM | Subject: Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub? | | When I use the following url: | | http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz | | I get: | | /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found | | | instead of my package downloaded ... the mcz file used to be there | and it does show up in the listing for | | http://smalltalkhub.com/mc/dkh/metacello/main | | the repository ... In fact none of the packages in the metacello | repository are accessible... | | Part of the site must down? | | | Dale | |
Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
I didn't forget the main part ... the url supplied by the listing at: http://smalltalkhub.com/mc/dkh/metacello/main is leaving 'main' off... Dale - Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Sunday, June 23, 2013 12:36:55 PM | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub? | | its here: http://smalltalkhub.com/mc/dkh/metacello/main | | = you forgot the /main part | | On 2013-06-23, at 21:32, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | When I use the following url: | | http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz | | I get: | | /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found | | | instead of my package downloaded ... the mcz file used to be there | and it does show up in the listing for | | http://smalltalkhub.com/mc/dkh/metacello/main | | the repository ... In fact none of the packages in the metacello | repository are accessible... | | Part of the site must down? | | | Dale | | | | |
Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
Cami, Did you confirm that smalltalkhub is producing incorrect urls? Dale - Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Sunday, June 23, 2013 12:46:03 PM | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missingon smalltalkhub? | | rewind, | what exactly are you doing? | in which image? | | | = the listing has some issues with the relative links, AFAIK that | has also been there for a while | doing adding a trailing slash usually solves this problem: | | http://smalltalkhub.com/mc/dkh/metacello/main/ | | On 2013-06-23, at 21:39, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | I didn't forget the main part ... the url supplied by the listing | at: | | http://smalltalkhub.com/mc/dkh/metacello/main | | is leaving 'main' off... | | Dale | | - Original Message - | | From: Camillo Bruni camillobr...@gmail.com | | To: Pharo Development List pharo-dev@lists.pharo.org | | Sent: Sunday, June 23, 2013 12:36:55 PM | | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on | | smalltalkhub? | | | | its here: http://smalltalkhub.com/mc/dkh/metacello/main | | | | = you forgot the /main part | | | | On 2013-06-23, at 21:32, Dale K. Henrichs | | dale.henri...@gemtalksystems.com wrote: | | | | When I use the following url: | | | | http://smalltalkhub.com/mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz | | | | I get: | | | | /mc/dkh/metacello/Metacello-ToolBox-dkh.131.mcz not found | | | | | | instead of my package downloaded ... the mcz file used to be | | there | | and it does show up in the listing for | | | | http://smalltalkhub.com/mc/dkh/metacello/main | | | | the repository ... In fact none of the packages in the | | metacello | | repository are accessible... | | | | Part of the site must down? | | | | | | Dale | | | | | | | | | | | | | |
Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
- Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Sunday, June 23, 2013 12:46:03 PM | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missingon smalltalkhub? | | rewind, | what exactly are you doing? | in which image? | | | = the listing has some issues with the relative links, AFAIK that | has also been there for a while ? I got an EOCD error loading Metacello-ToolBox-dkh.131 into GemStone during a travis ci job[2]... A month ago I reported a bug[1] and figured that the error was possibly related so I went to the site and used the http://smalltalkhub.com/mc/dkh/metacello/main/ url to look at the available packages (like I do with all of the other mcz repositories) to confirm that the package was there and that it was not corrupted ... when they all turned up giving me errors I figured that something else was broken and sent the mail ... I didn't realize that this listing has always been broken in smalltalkhub ... The EOCD error was probably just a transient problem and I was fooled into thinking that the site was truly broken ... sorry about that... Dale [1] https://code.google.com/p/smalltalk-hub/issues/detail?id=21 [2] https://travis-ci.org/glassdb/glass/jobs/8366726#L546 [3] https://travis-ci.org/glassdb/glass/jobs/8366726#L546
Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?
- Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Sunday, June 23, 2013 12:53:44 PM | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mczmissing on smalltalkhub? | | | On 2013-06-23, at 21:48, Dale K. Henrichs | dale.henri...@gemtalksystems.com wrote: | | Cami, | | Did you confirm that smalltalkhub is producing incorrect urls? | | if you omit the trailing slash and click on a link of the version | list in a browser, then yes. | Cami, Smalltalkhub itself omits the trailing slash[1]: MCHttpRepository location: 'http://smalltalkhub.com/mc/dkh/metacello/main' user: 'dkh' password: '' That's probably where I copied the link from to look at the full list of packages ... _I_ didn't do the omitting:) Dale [1] http://smalltalkhub.com/#!/~dkh/metacello
Re: [Pharo-dev] you may need to update your configurations
Thierry, File names are not necessarily unique in the Monticello universe, if the UUIDs match then they are the same ancestor... Dale - Original Message - | From: Goubier Thierry thierry.goub...@cea.fr | To: Pharo Development List pharo-dev@lists.pharo.org | Sent: Wednesday, June 19, 2013 8:15:48 AM | Subject: Re: [Pharo-dev] you may need to update your configurations | | | | Le 19/06/2013 17:01, Christophe Demarey a écrit : | | Le 19 juin 2013 à 16:36, Goubier Thierry a écrit : | | By the way, why the change in | MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? | | Because this change comes from the FileTree branch used fro Pharo3 | [1]. | This small change avoid to use a deprecated method in Pharo3. | It should not be used in Pharo2. | | [1] | https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc1abe0bfa120f3 | | Thanks. It's just that the latest filetree-core-pharo20 package has | MonticelloFileTree-Core-ChristopheDemarey.97 as ancestor :) | | Probably me messing a merge in my filetree fork. I'm supposed to | branch | from the pharo20 branch, and I can see your version as well... | | Thierry | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 | |
Re: [Pharo-dev] metacello conditional loading
Cami, The expression: MetacelloPlatform current defaultPlatformAttributes will list the platform attributes at the system level (default). The expression: ConfigurationOfXXX project platformAttributes will list the set of attributes defined for a particular configuration (presumably a superset of the default set). If you look in MetacelloPharoPlatformdefaultPlatformAttributes, you'll see the following: defaultPlatformAttributes | attributes versionString | ((Smalltalk respondsTo: #image) and: [ Smalltalk image respondsTo: #metacelloPlatformAttributes ]) ifTrue: [ ^ Smalltalk image metacelloPlatformAttributes ]. . The method #metacelloPlatformAttributes let's you define exactly the set of attributes that you want supported for pharo platforms ... Hope this helps, Dale - Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: pharo-dev@lists.pharo.org | Sent: Monday, June 17, 2013 6:41:00 AM | Subject: [Pharo-dev] metacello conditional loading | | - where do I find a list of the magic tags I can use for conditional | loading? | - is `spec for: #'pharo3.x' version: '3.0'` already supported? | | thanks | |
Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ?
Thierry, I'm on vacation this week, but I will be integrating your change into Metacello ... thanks man! Dale - Original Message - | From: Goubier Thierry thierry.goub...@cea.fr | To: Discusses Development of Pharo pharo-dev@lists.pharo.org | Sent: Wednesday, May 22, 2013 7:48:49 AM | Subject: Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ? | | Le 22/05/2013 15:26, Camillo Bruni a écrit : | | On 2013-05-22, at 15:22, Goubier Thierry thierry.goub...@cea.fr | wrote: | | Le 22/05/2013 15:12, Camillo Bruni a écrit : | | On 2013-05-22, at 15:05, Camillo Bruni camillobr...@gmail.com | wrote: | | Not sure I can answer that; in the meantime, I just added a | FileTreeUrl as a | subclass of FileUrl, and Gofer seems happy with that. | | Neat. | | Now, I can do: | | ./pharo Pharo.image eval --save Gofer new url: | \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; | load | | cool! | | And a long time after (package loading is slo), it's done. | | However, the --install in the config handler doesn't work; had | to use --install=stable instead. | | that's in 2.0 I guess, since I changed it to use #stable by | default in 2.0. | So we should push the FileTreeUrl into the 2.0 repository for | FileTree.. | | or simpler, change the command line handler to use GenericURL | | Well, with FileTreeUrl, if you have a config in your filetree | repo, you can use config filetree:///whatever ConfigurationOf; no | need to change the ConfigurationCommandLineHandler for that. | | I haven't done a ConfigurationOf for that project, so I wanted to | load packages by packages (hence the eval) but you'll notice this | is almost the same code as ConfigurationCommandLineHandler. | | yes, I came to the same conclusion: | https://github.com/dalehenrich/filetree/issues/74 :) | | I've uploaded a MonticelloFileTree-Core package with a FileTreeUrl in | it | in the ss3 FileTree repository. | | Thierry | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 |
Re: [Pharo-dev] Messy Configurations
- Original Message - | From: Camillo Bruni camillobr...@gmail.com | To: pharo-dev@lists.pharo.org | Sent: Wednesday, May 22, 2013 8:53:31 AM | Subject: [Pharo-dev] Messy Configurations | | I recently spent some time to revise how to write Metacello | Configurations. | | Observation: | | - many configurations are quite a mess | - many configurations duplicate code internally | - many configurations have archived development versions | | | For Pharo 3.0 I made a new Configuration template which improves and | documents | these observed points in quite some detail. Simply load a new 3.0 | image and | create a new configuration from the monticello working copy browser. | | Solution: | = | - specify external projects in separate, reusable methods | - only have ONE development version you regularly update | - do not use version numbers for the development version | - only make a version number when you release something stable AKA | not #development | - name the baseline after the first version that introduces it | | | | What do you think? Cami, I don't want to discount your frustration with the complexity of Metacello configurations and looking at your sample configurations you have definitely come up with a cleaner structure for the code ... But, (there always is a _but_) ... Metacello configurations are not really code ... they are specifications ... Metacello configurations are closer to XML files than they are to Smalltalk classes ... XML files are read by tools and written by tools ... You can hand edit an XML file to produce a pleasing structure for human readability, but when a tool gets ahold of the file and rewrites the XML file, all of the fancy hand editing disappears ... The same thing will happen with configurations ... you can restructure the code in your configuration using nicely structured methods, etc, however, if you use a tool to add/manipulate your configuration, all of the fancy formatting will be lost and the tool will write out a monolithic single method representation of your specification (leaving the rest of the configuration methods untouched) ... With that said, it is conceivable that a crop of tools can be written to produce better structured configurations ... meaningful pragmas could be invented so that tools and humans could both be aware of the project methods and other components that you've added ... but that is up to the tool builders ... Dale
