[Cuis] Cuis
Locked
12345
... 9
12345
... 9
 
|
>> There would also be a minimal, seaside, pier, seaside-magma-pier-
>> beach, >> developer and "fun" one click images amongst others. > > The key word here is 'would'. > Get back, when you can say 'is', otherwise don't expect someone > _would_ buy this. You are an incurable cynic. I say "was", in reference to 3.10 and "would" in reference to 3.11, 3.12, and 3.13 because they don't exist. The process for producing these artefacts "was" available and running on a dedicated server. Bob was building one click images from 3.10. Bob was building developer images, based upon damiens definitions in Sake/Packages form 3.10 The seaside, and seaside magma pier image is simply a varient of the above. The only stretch in the imagination is the "fun" image because despite a year of requests Edgar refused to put together a Sake/Packages definition that would generate it. Keith |
|
|
In reply to this post by keith1y
On Jan 21, 2010, at 12:40 PM, keith wrote: >> >> >> Nonsense. In the past 6 months, just to take three that come to mind, we have closures, native fonts and unloadable smaller traits. There are lots of other things also; go look at the recent changes list. Trunk is actually progressing very nicely. >> >> You might try contributing code rather than whining at length. It's more fun for everyone. Better for the community > > Where are these things, are they in a released image? http://ftp.squeak.org/current_development/ http://ftp.squeak.org/current_development/Squeak3.11-8472-alpha.zip I'm guessing from the way this thread is going that you won't count as "released images". Please prove me wrong. I admit that, in a way ,they aren't (as attested by the -alpha tag). But I hope that you admit that they do constitute releases in some meaningful sense. Josh |
|
|
In reply to this post by Josh Gargus
Josh Gargus wrote:
> On Jan 21, 2010, at 12:21 PM, keith wrote: > >> We set the goal "We don't want an image, we want a kernel, that you can build distributions from." So what do you and the board do? Yep the opposite! You build a monolithic image using a process that can only build a monolithic image. > > Off the top of my head, what about the fact that Traits are now unloadable/reloadable? As well as ReleaseBuilder, ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader, SMBase, Installer-Core, VersionNumberTests, VersionNumber, Services-Base, PreferenceBrowser, Nebraska, CollectionsTests, GraphicsTests, KernelTests, MorphicTests, MultilingualTests, NetworkTests, ToolsTests, TraitsTests, XML-Parser, Traits, SystemChangeNotification-Tests, FlexibleVocabularies, EToys, Protocols, Tests, SUnitGUI. Cheers, - Andreas |
|
|
> Josh Gargus wrote: >> On Jan 21, 2010, at 12:21 PM, keith wrote: >>> We set the goal "We don't want an image, we want a kernel, that >>> you can build distributions from." So what do you and the board >>> do? Yep the opposite! You build a monolithic image using a process >>> that can only build a monolithic image. >> Off the top of my head, what about the fact that Traits are now >> unloadable/reloadable? Very good. Is it the same simpler traits as pharo? > As well as ReleaseBuilder, ScriptLoader, 311Deprecated, > 39Deprecated, Universes, SMLoader, SMBase, Installer-Core, > VersionNumberTests, VersionNumber, Services-Base, PreferenceBrowser, > Nebraska, CollectionsTests, GraphicsTests, KernelTests, > MorphicTests, MultilingualTests, NetworkTests, ToolsTests, > TraitsTests, XML-Parser, Traits, SystemChangeNotification-Tests, > FlexibleVocabularies, EToys, Protocols, Tests, SUnitGUI. We reorganised all the test classes to be more logically organised, next to the package they are testing, while at the same time being unloadable and loadable. However the reorganisation required a different PackageInfo which you cant load using your process. Also MC1.5 has its tests in a separate package. We made Nebraska unloadable, and put the loadable package in Sake/ Packages, because the process for making things unloadable was to load an unloadable version of Nebraska, over the top of the original. You haven't actually really done anything then on this topic then. Keith |
|
|
In reply to this post by Andreas.Raab
Oh and if you want to actually remove SUnit there is a dummy stub
package in squeaksource.com/Testing Keith |
|
|
In reply to this post by keith1y
On Jan 21, 2010, at 1:34 PM, keith wrote: > >> Josh Gargus wrote: >>> On Jan 21, 2010, at 12:21 PM, keith wrote: >>>> We set the goal "We don't want an image, we want a kernel, that you can build distributions from." So what do you and the board do? Yep the opposite! You build a monolithic image using a process that can only build a monolithic image. >>> Off the top of my head, what about the fact that Traits are now unloadable/reloadable? > > Very good. Is it the same simpler traits as pharo? What's your point? I responded to your false statement that the process "can only build a monolithic image". I'm not talking about cross-fork compatibility here. Josh |
|
|
I write and maintain packages for users in both squeak and pharo, surely my point is obvious, I don't want extra work, and I dont want to have to maintain separate code bases. I was just hoping for a simple answer, "yes" would be good. I wasn't being cynical, I was just interested to know.
I can unload packages from any image with Sake/Packages, I dont need the trunk process for that, but lets see your process build an image without Monticello, or with Morphic3, or Rio instead of FileDirectory. Basically you are not able to offer anything fundamentally different from what has gone before, I don't want File/Directory in my image I hate it with a passion. My entire motivation for hacking the core in the first place is to get rid of FileDirectory. "Fail to plan plan to fail", I think the saying goes. Keith |
|
|
In reply to this post by keith1y
Ok I stand corrected, you have done something, I didn't see Etoys in the list before. Keith |
|
|
In reply to this post by Eliot Miranda-2
Hi Elliot, First of all these things are of no use to me, because my code base will take about 2 months to port, longer since I now have to port the tools as well. You might think you are doing the community a service, but actually you haven't provided stuff or "captured knowledge" that the existing community can use easily. All you have done is encouraged some members of the community to abandon the rest of us, moving over to developing stuff for a new image that I cant use, leaving behind compatibility. My production images don't have closures, the customer asks for an update, I cant load the latest seaside if it uses closures for example. This is the same as the pharo "stuff compatibility" attitude and they are also developing stuff I cant use. For example, Magma runs in Pharo and 3.7 - 3.10, apparently you provide closures, but if closures aren't available as a loadable/applyable feature for 3.7 then magma has to choose either not bother to use closures, maintain two or three codebases, or drop support for older images. The knowledge to implement closures has been redone 3 times now, in trunk, pharo, and cuis, but I don't have the expertise to do it myself. I think you misunderstand me my gripe is not about making progress, it is about throwing all the knowledge into one disorganised pot, aka "trunk". If you had kept the knowledge needed to implement closures as a separate initiative, in a separate repo, with separate change sets, scripts etc then other people could harvest that knowledge, either all or in part, and you would be contributing "knowledge" that I could import into my codebase. Perhaps cobalt would like closures too. Cobalt is not going to be able to move to build on trunk-alpha overnight either, so they are going to have to do it all over again. The same goes for bug fixes. Previously we had 100 fixes ready to load into 3.10 from mantis, all documented, and supplied in their natural form "changesets". Throwing fixes into trunk, dilutes the knowledge, and makes it only useful for trunk users and no one else. I cant harvest a fix out of trunk, into my image. I suggested a compromise back in August, that Andreas ignored completely. That if trunk development was split into clearly defined initiatives with separate projects, then we would be able to work together. Again feel free to correct me if I am wrong. Keith |
|
|
In reply to this post by keith1y
On Jan 21, 2010, at 3:10 PM, keith wrote:
Fair enough. I believe that Andreas went to some lengths to maintain compatibility.
I never claimed that the trunk process is necessary for package unloading. You're the one who claimed that the trunk process can only build a monolithic image, and I debunked it with a counter-example. I realize that you're responding to emails from many people, but let's please try to follow the argument, otherwise we're all wasting our time.
Cheers, Josh
|
|
|
> No, it was not obvious. Even upon rereading, it doesn't seem like > you're conceding that your statement that the process "can only > build a monolithic image" is mistaken... it seems like you're trying > to change the subject. Josh, You are correct I am not conceding the point, that you can only build a monolithic image. Could you build an image with the same contents as cuis using this trunk process, I don't think so. Could you maintain and build images based on cuis using this process, again no. The community has been asking for a kernel minimal image for years, I think it is somewhat short-sighted to propose a development process that cannot actually fulfil the goal. > I never claimed that the trunk process is necessary for package > unloading. You're the one who claimed that the trunk process can > only build a monolithic image, and I debunked it with a counter- > example. Monolithic image, to me means, an image in which the code loading tools, the compiler, the UI, the transcript etc are all tied in extricably together and will never part. >> Basically you are not able to offer anything fundamentally >> different from what has gone before, > > In terms of unloading packages, maybe not (are you now admitting > that real progress has been made in that regard?). But in terms of > pace of development, obviously so. Pace of development is no different. If Andreas had said in his original email, "Lets all get cracking on using Keith's stuff that he is documenting for us in the screen casts he released yesterday", then the pace of development would be identical. He didn't instead he said, "hey everyone I knocked this up trunk thing up over a weekend lets all pile in". Alternatively if Andreas had said, "we now have the test and integration server to integrate new initiatives, so how about proposing some new initiatives, and get cracking on them, now you can be assured that they will be integrated in your allocated slot in the process." then pace would have been much faster, because everyone's contributions would be testable, and usable. Whereas for example if I contribute the message eating Null to trunk, I bet you a tenner Andreas will take it out again. I didn't pick a slow development process on purpose to thwart people contributing. I didn't ask for direct contributions because we already had about 200 ready to load automatically from mantis thanks to Mr Cellier. In bob 3.11 the image was already tracking mantis, so all you had to do to make a contribution was to switch the status of the fix to "testing" in mantis, and it would be integrated in the next build. The Bob based process, asks people to work on initiatives in their own development area, and hook the results of those initiatives into a continuous integration and testing process which produces an alpha image. This would arguably be faster, because you wouldn't have people treading on each others toes. Secondly you wouldn't have to integrate anything into the release image that wasn't 100% complete and tested. Thirdly your image is regression tested against all packages that use it, AND there is a mechanism for fixing broken packages and feeding the fixes back to their maintainers. The bob process was not just maintaining the image, it was also able to contribute to maintaining the entire squeak code base. How else would I be able to plan to eradicate FileDirectory. regards Keith |
|
|
In reply to this post by keith1y
2010/1/21 keith <[hidden email]>:
> >> All 'grand' projects growing out from small ones. Which makes little >> ones as much as valuable >> as any of your 'grand' project. I'd prefer seeing 10 little projects >> popping out each month, than >> 1 grand project popping out once in 2 years. > > Igor, > > I think you need to think about what you are saying more carefully, you are > arguing against yourself here. > > The trunk process is a "grand project" which hasn't produced anything of any > use for 6 months. It signs up the community for an ongoing wait of 12-18 > months per release. It ties you in to the "grand project" ethos which we all > said we didn't want. > > My process produced a stream of useful projects popping up along the way at > regular intervals, that is what you are saying you want isnt it? > > We set the goal "We don't want an image, we want a kernel, that you can > build distributions from." So what do you and the board do? Yep the > opposite! You build a monolithic image using a process that can only build a > monolithic image. > > Furthermore the process I produced (and finished) with Bob, was designed to > produce monthly or bi-monthly releases, with all fixes auto documented. > Which is also what we wanted. The goal is to "release early and often", so > what does the board do, yep exactly the opposite. A new process that will > take a year to produce anything, and nothing will be auto-documented. > > So you say you want something every month or so, but defend to the hilt the > process which will NOT deliver it. > > You had a release of Bob, in an image, loaded for you to play with in > February (did you download it?), you had a release of Sake/Packages 18 > months ago (you told me you didn't use that either). The problem is that you > all seem to say you want small projects popping up regularly, but when they > pop up you dont use them. Furthermore you seem to be working arduously to > make those small projects, which apparently you desperately want, > irrelevant, and obsolete, when they are still useful, and in use today. > > We want squeak to go forwards not backwards. > > There was no grand project, to produce the 3.11, there was a process. In > case you don't know, a process is a way of thinking about the problem, and > applying yourself to achieve a defined goal. The board approved this goal to > provide this process. The process was being used, and was working. It had > not quite produced a result yet, but I was making videos showing THE PROCESS > which was the deliverable of the 3.11 effort was not an image, but the > process that would enable to community to build future images, and that is > what I was documenting and making videos of. > > The actual deliverable of 3.11 could have been produced any time, the script > was written 18 months ago. 60% of it was in LPF already, and we had plenty > of users, and a downloadable image. All you had to do was run the script > manually. Ken Brown had a go, he was convinced. But the deliverable was not > the image it was the process, that is what the board approved, so having a > go at me for not producing an image, is moving the goal posts. > > The purpose of this process was to support extreme programming practices for > all users of squeak, but showcased in the release of 3.11. Now we are locked > in to a "wait 18 months for a release process all over again". > > I never advocated a grand release process, that's what I am complaining > about, the dog returning to its vomit. We already decided that this wasn't > the way forward. > > Your choice to mock me, master Yoda, is hardly commensurate for a positive > way forward. > I am mocking, because you seem walking in circles. And you presented a number of valid points in this topic. But that's not the point. My point that theiy don't having any value, if you don't stop being destructive, destroying a good relations with everyone you know here. Who's gonna follow you? Who's gonna help you with implementing them? Who's gonna use the artifacts you made, knowing that at some moment, you can declare everyone as enemy an simply stop being supportive? > My point I still don't think you are getting, is that while squeak is > running on an 18 month release cycle producing a monolithic image, which > only serves the vision of the person who built it, and processes are locked > in to that way of thinking, it is already irrelevant, hence my search for > something else. > > Within the Smalltalk community which invented extreme programming, we are > basically a bit of a laughing stock, since we cannot produce a release in 20 > minutes. > > Keith > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by keith1y
Keith, if you still didn't understood my message, let me elaborate.
1. All your ideas/arguments about techical issues is highly rational. 2. But instead of using power of arguments, and looking for compomises, you choosen to fight with everyone, defending your position, up to the point, that it is not really matters, who is right or wrong , and in what they right or wrong. You just subbornly keep fueling a conflict, which nobody, except you want to have. This is irrational. Here the formula, which you should learn: rational*1000000^100000 + irrational / (100000^100000) = irrational. -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by keith1y
On 2010-01-21, at 5:12 PM, keith wrote:
Keith I see Eliot's not responded, I think he's busy elsewhere. But your example here is completely off-base. The Squeak community resisted doing closures for *years*, and under their breath muttered no friggen closures in squeak, but that's so simple to do... Why: (a) It would break things and *force* people to migrate their code at *their expense*. The VM architects were extremely aware that was just the way it was going to be. Eliot proposed a clean solution and pushed out the VM changes and changes sets against a older Squeak/Pharo image to exploit it. I build a VM off that so someone could at least run it. The Pharo community then took the VM, change sets and reviewed their code base for additional fixes, later the same happen with the Squeak trunk. If there is stuff not converted then ask yourself is anyone supporting that code? If it's your stuff, then either you or others you convince will have to convert it. -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
|
|
In reply to this post by keith1y
On Thu, Jan 21, 2010 at 5:12 PM, keith <[hidden email]> wrote:
But lots of other people are using the progress just fine. Pharo is harvesting work from Squeak and vice verce. All it takes is will and knowledge of the available tools. Monticello is a huge enabler.
That's one viewpoint (an intellectual horizon of radius zero as Albert said). From another perspective what I've done is set the stage for a series of VMs which have significantly better performance, the first (in use at Teleplace) showing 5x the performance of the existing VMs, eliminated a major short-comming of the Squeak/Pharo execution core by eliminating non-reentrant blocks and providing the ability to write much cleaner code, and have made Squeak/Pharo execution semantics ANSI-compliant and equivalent to other leading dialects.
If you hadn't spend the last 6 months having a hissy fit you would find you weren't as far behind or as inconvenienced. You might also have participated in porting the closure bootstrap (which does exist as changesets on my blog site and has been adapted to three different Squeak distros so far) to your context. Instead you've chosen to disengage, and make a signally unconstructive return. I find myself unsympathetic to your concerns.
and what would be the point of maintaining an evolving package for old images? Eventually the old becomes the obsolete; the cost-benefit ratio falls below 1. If you want to be a curator then that's up to you, but I get the impression that this community wants to be productive and self-expressive. The past is past.
(& BTW the knowledge on how to implement closures is widespread (mine is based on a lisp implementation strategy), and what you're talking about is the bootstrap, not the implementation).
Whatever. Looks like you failed over two years to make a new release, got upset when people finally lost patience and started work again, and that you lack the objectivity to realise your part in your misfortune.
Again, the change sets are there, but one problem with change sets is the lack of tool support for evolving them. The only way I know is to manually back-merge fixes. Alas I can't afford the time; I have further progress to make.
The usefulness of both changesets and packages and the tensions between them is a really interesting and large topic that I'm not going to address here, but putting things in well-defined packages that can be unloaded from a trunk image does not dilute important knowledge (the change history in a package is richer than in a changeset, as there are multiple changes, each with a comment) and is clearly more useful to users other than trunk users because of the degree of interchange between Pharo, Squeak and Cuis that is obvious at the moment (new text editor, faster buffered file reading, native fonts, etc, etc). These exchanges are being done by people who are happy with Monticello but more interested in the message than the medium. Your criticisms seem very much to me like sour grapes from one who is set in his ways and wants to take his marbles away because others want to play a different game. You were the one who wouldn't release Bob open source.
Is that what you were doing? I thought you were flinging mud. I certtainly didn't get the impression you were offering a compromise.
I think I'm pissing in the breeze. Surprise me if I'm wrong.
Eliot |
|
|
In reply to this post by Igor Stasenko
> Write tool to leverage the trunk activity then. Stop whining about > losing control (via Mantis). > People like a new and easy way to contribute, otherwise nobody would > put any commits in trunk. > Is this something that hard to understand? Is there somewhere a list of the users that have commited changes to the trunk? Or how many people have been contributing with this new model? I for sure have seen commits from Levente Nicolas Cellier Andreas Raab Who else? Is an honest question. -- Miguel Cobá http://miguel.leugim.com.mx |
|
|
El jue, 21-01-2010 a las 22:53 -0600, Miguel Enrique Cobá Martinez
escribió: > > Write tool to leverage the trunk activity then. Stop whining about > > losing control (via Mantis). > > People like a new and easy way to contribute, otherwise nobody would > > put any commits in trunk. > > Is this something that hard to understand? > > Is there somewhere a list of the users that have commited changes to the > trunk? > Or how many people have been contributing with this new model? > > I for sure have seen commits from > Levente > Nicolas Cellier > Andreas Raab > Even better would be a list with number of commits per person. Just to know. > Who else? Is an honest question. > > Thanks -- Miguel Cobá http://miguel.leugim.com.mx |
|
|
In reply to this post by Igor Stasenko
1) I proposed a workable compromise immediately after Andreas' original email, it was ignored!!!! 2) There is no compromise, you aren't providing me with a workable solution. I can't use trunk, the trunk process is not managing anything of interest or use to me or my client because I was providing tools. a) tools that trunk cant load and b) and tools that are managed outside of trunk, Since anything outside of trunk is ignored as a possible solution, because you still have your monolithic blinkers on, and the board is still driven by the idea that "oh my goodness Pharo has a new image and we dont". You are forgetting that in Bob you have a viable "extreme programming style continuous integration development platform", when in Pharo they don't, but Bob is ONLY viable IF YOU USE IT. When you have a project manager whose goal is to produce an image with fancy fonts (lol), rather than a "comprehensive extreme programming capable development platform", you are going to produce conflicting strategies. You are all so wrapped up in hacking trunk, you aren't the slightest bit interested in moving forward on the tools. Sure Andreas wants a package manager, on his terms only though. I cant port my production images to trunk easily, and when 3.11 is released, I could spend 2/3 months porting my stuff, but since you lot wouldn't even do me the courtesy of starting with 3.10-build, you make it harder for me. You are also probably going to pick a different package management system so all my current package definitions will have to be redone from scratch, any work I do or have done on tools has been discarded by you lot. I rejoined squeak-dev and started the fight again, because I suddenly realised that you had actually left me in a position where I had no way forward at all, I had thought I could move to pharo, until I actually tried their image, ugh, what a disaster (OmniBrowser) and guess what, all my package definitions will have to be redone from scratch. Anyhow in six months time the client is going to say, "what shall we do next" and I will end up saying, why don't you get someone else to do it in python or whatever you like, because squeak is not a viable platform any more, nor is pharo. The viability of the platform is entirely bound up in the politics, and the ability of the community to collaborate and share stuff more than the technical side of things. Witnessing one individual overrule that the way forward is a hacking away unplanned process, to produce an incompatible image, without any tools being provided for us to use in our work, is damaging for the viability of squeak as a professional development platform. Then it appears that there isn't the will in the community to develop, provide, support and USE the tools we need to do a professional tested job. The current focus of the community as endorsed by the board is on hacking at trunk which is an irrelevant task as far as we are concerned since our starting image is basically arbitrary because we use an automated build, 3.8 works fine for us. Cuis is an attractive target as anything because it is small and fast. (but it has no tools yet!) However now that the "release-team" is hacking at trunk, rather than providing a working process and tools which we could adopt in-house to do a good professional job for our clients. Squeak ceases to be an interesting platform because it hasn't got any continuous integration tools, it has no vision for such tools, and those it has got have just been discarded by the community without a second thought. Now if I continue to develop these tools for my use only, while you are all hell bent on building trunk and doing everything is exactly the opposite way that is of any actual use, using either no tools or other tools that are not compatible with my tools. I will not and cannot compete, you win, and my client will end up back with python where they started. Juan has it right, his vision is to produce "the best kernel he can", but not on any account to interfere with the users of the kernel and what they might want to do with it. This frees me up to implement "a grand vision", without having it trashed at a moments notice, by someone else coming along with a lesser vision. My client chose squeak because of the potential and the open collaborative dynamics of the community that they saw on irc that were interested in tools, and extreme programming approaches, particularly release often, and test always. If I use BOB to build and regression test my code it only makes sense if the seaside team also uses Bob to build and regression test their code and the same goes for magma etc etc. Those dynamics and collaborative dynamics have now gone, as has the interest in tools and its a case of what Andreas says goes, and what Andreas says is we are going to produce a 3.11 image come hell or high water without tools, without regression testing and without a rapid release cycle integrating carefully planned and proven projects which are separately published. Neither the squeak board or the trunk developers are doing anything to make squeak a first class development platform that is developed daily using continuous integration and extreme programming tools and techniques. There is this new 3.11 image promised down the line, but its not developed with our needs in mind, it isn't developed with the tools we want to use, it isn't tested against the packages we want to use yet, and uncle Tom Cobbly (anyone) can change an API at the drop of a hat. Oh and it will be a year until the subsequent release. 3) The board is not providing a compromise basis either, since it refuses to provide "terms of reference".
I am only virtually fighting against the impossible situation you have put me in, and the complete lack of thinking going on here. To be clear once more, I can build an production image on any base image, so the trunk image itself is irrelevant. What is relevant is the process by which the 3.11 image is developed on an ongoing basis, and the bug fixes that are published against individual releases. If I choose 3.11 as the basis for a project I want to know that bug fixes will be provided for THAT image, not for trunk2, the client wants to know that bug fixes are available for an image that has a bug found in it, not an image that we have to wait 18 months for. I am also fighting against those who don't bother communicating. For example Craig where are you, you are as responsible for this mess as anyone else. Andreas nor the board didn't email me for 2 months to ask for a progress update. You will see I mellow somewhat as people who enter into a conversation with me, I mellow. Elliot talks sense, and Josh too. But no matter how much sense they make, no compromise is being offered, because you still see the future of squeak as an image release, and I see it as a development platform and series of processes that need tools (which don't care about the image). While the board puts the power into Andreas' hands to dictate the future of squeak, there is no future of squeak the development platform, there is only a 3.11 image, big deal.
While you continue to use the argument "the end justifies the means" you are picking the fight. Just because no one stands up to you, doesn't mean it is an acceptable attitude to have. The fact that "the end" in this case is to divert valuable resources into an minimally relevant hole called "trunk". Plot the number of users of images derived from 3.7, 3.8, 3.9, and 3.10 see how it falls. 3.8 still has the most users, 3.11 will have about 20 users max by the time you have finished. Like I said "Terms of Reference" are important, but a new image developed without tools is not. The deliverable of squeak, is a published image, AND a toolset for building and deriving distribution images, AND up to date package definitions for all packages, AND a Bug Tracker that is used to publish Bug fixes against said published image. You are right I don't expect any compromise to be possible. Andreas has it nailed up so there isn't any possible. But at least this way people might actually think... cheers Keith |
|
|
In reply to this post by Miguel Cobá
Miguel Enrique Cobá Martinez wrote:
> Is there somewhere a list of the users that have commited changes to the > trunk? Try this: bag := Bag new. (MCHttpRepository location: 'http://source.squeak.org/trunk' user: '' password: '') allFileNames do:[:fname| (fname endsWith: '.mcz') ifTrue:[ bag add: ((fname copyAfterLast: $-) copyUpTo: $.)]]. bag sortedCounts. Cheers, - Andreas |
|
|
In reply to this post by Miguel Cobá
Hi,
Am 22.01.2010 um 05:58 schrieb Miguel Enrique Cobá Martinez <[hidden email] m>: > Even better would be a list with number of commits per person. Just to > know. ... to know what? >> Who else? Is an honest question. I've committed a thing or two, but these things are much much less important and relevant than the contributions of the people you already mentioned. I don't know if there's a list in the form you asked for somewhere, but the long list on http://source.squeak.org/trunk/ could surely be used to extract that information with a simple shell script ... too bad I'm not on my Mac right now. :-) Best, Michael |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |