Release candidate Squeak4.4-12320 ready
Locked
1234
1234
Release candidate Squeak4.4-12320 ready
 
|
* http://ftp.squeak.org/4.4/Squeak4.4-12320.tgz
* http://ftp.squeak.org/4.4/Squeak4.4-12320.zip This should fix the MC failing tests. Thanks, Colin! frank |
Re: Release candidate Squeak4.4-12320 ready
|
|
Great! I was Christmas shopping last night and missed all the activity. That eliminates all the MC failures. Were back to the some old three. I have one additional failure with Squeak 4.3 VM. ProcessTest>>#testAtomicSuspend. Here's the stack:
20 December 2012 11:29:45.179 am VM: Mac OS - Smalltalk Image: Squeak4.4 [latest update: #12320] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/eglenpaling/Documents/Smalltalk/Squeak 4.4 Testing/Squeak-4.3-All-in-One with 4.4RC inserted.app/Contents/Resources Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/eglenpaling/Library/Preferences/Squeak/Internet/My Squeak ProcessTest(TestCase)>>signalFailure: Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: aString: 'Assertion failed' Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil ProcessTest(TestCase)>>assert: Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: aBooleanOrBlock: false Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil ProcessTest(TestCase)>>shouldnt:raise: Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: aBlock: [closure] in ProcessTest>>testAtomicSuspend anExceptionalEvent: Error Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil ProcessTest>>testAtomicSuspend Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: p: a Process in [] in ProcessTest>>testAtomicSuspend sema: a Semaphore(a Process in [] in ProcessTest>>testAtomicSuspend) list: #(nil) Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil ProcessTest(TestCase)>>performTest Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil [] in [] in ProcessTest(TestCase)>>runCase Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil BlockClosure>>on:do: Receiver: [closure] in [] in ProcessTest(TestCase)>>runCase Arguments and temporary variables: exception: an ExceptionSet handlerAction: [closure] in [] in ProcessTest(TestCase)>>timeout:after: handlerActive: false Receiver's instance variables: outerContext: [] in ProcessTest(TestCase)>>runCase startpc: 62 numArgs: 0 [] in ProcessTest(TestCase)>>timeout:after: Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: <<error during printing> Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil BlockClosure>>ensure: Receiver: [closure] in ProcessTest(TestCase)>>timeout:after: Arguments and temporary variables: aBlock: [closure] in ProcessTest(TestCase)>>timeout:after: complete: nil returnValue: nil Receiver's instance variables: outerContext: ProcessTest(TestCase)>>timeout:after: startpc: 153 numArgs: 0 ProcessTest(TestCase)>>timeout:after: Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: aBlock: [closure] in [] in ProcessTest(TestCase)>>runCase seconds: 5 delay: a Delay(5000 msecs) watchdog: a Process in Process>>terminate theProcess: #(nil) Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil [] in ProcessTest(TestCase)>>runCase Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil BlockClosure>>ensure: Receiver: [closure] in ProcessTest(TestCase)>>runCase Arguments and temporary variables: aBlock: [closure] in ProcessTest(TestCase)>>runCase complete: nil returnValue: nil Receiver's instance variables: outerContext: ProcessTest(TestCase)>>runCase startpc: 45 numArgs: 0 ProcessTest(TestCase)>>runCase Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil [] in ProcessTest(TestCase)>>debug Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil BlockClosure>>ensure: Receiver: [closure] in ProcessTest(TestCase)>>debug Arguments and temporary variables: aBlock: [closure] in ProcessTest(TestCase)>>debug complete: nil returnValue: nil Receiver's instance variables: outerContext: ProcessTest(TestCase)>>debug startpc: 62 numArgs: 0 ProcessTest(TestCase)>>debug Receiver: ProcessTest>>#testAtomicSuspend Arguments and temporary variables: Receiver's instance variables: testSelector: #testAtomicSuspend timeout: nil [] in TestRunner>>debugSuite: Receiver: a TestRunner Arguments and temporary variables: <<error during printing> Receiver's instance variables: categories: #(#'KernelTests-Chronology' #'KernelTests-Classes' #'KernelTests-Me...etc... categoriesSelected: a Set() classes: {TestCase . AllocationTest . ArbitraryObjectSocketTestCase . ArrayLite...etc... classIndex: 0 classesSelected: a Set(WeakMessageSendTest MCAncestryTest SemaphoreTest Depende...etc... failedList: {LocaleTest>>#testLocaleChanged . ProcessTest>>#testAtomicSuspend ....etc... failedSelected: ProcessTest>>#testAtomicSuspend errorList: #() errorSelected: nil lastUpdate: 3533451867 result: 3272 run, 3245 passes, 23 expected failures, 4 failures, 0 errors, 0 un...etc... previousRun: nil categoryPattern: nil classPattern: nil [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every: Receiver: an OrderedCollection(ProcessTest>>#testAtomicSuspend) Arguments and temporary variables: <<error during printing> Receiver's instance variables: array: {ProcessTest>>#testAtomicSuspend . nil . nil . nil . nil . nil . nil . n...etc... firstIndex: 1 lastIndex: 1 OrderedCollection>>do: Receiver: an OrderedCollection(ProcessTest>>#testAtomicSuspend) Arguments and temporary variables: aBlock: [closure] in [] in OrderedCollection(Collection)>>do:displayingProgress...etc... index: 1 Receiver's instance variables: array: {ProcessTest>>#testAtomicSuspend . nil . nil . nil . nil . nil . nil . n...etc... firstIndex: 1 lastIndex: 1 --- The full stack --- ProcessTest(TestCase)>>signalFailure: ProcessTest(TestCase)>>assert: ProcessTest(TestCase)>>shouldnt:raise: ProcessTest>>testAtomicSuspend ProcessTest(TestCase)>>performTest [] in [] in ProcessTest(TestCase)>>runCase BlockClosure>>on:do: [] in ProcessTest(TestCase)>>timeout:after: BlockClosure>>ensure: ProcessTest(TestCase)>>timeout:after: [] in ProcessTest(TestCase)>>runCase BlockClosure>>ensure: ProcessTest(TestCase)>>runCase [] in ProcessTest(TestCase)>>debug BlockClosure>>ensure: ProcessTest(TestCase)>>debug [] in TestRunner>>debugSuite: [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every: OrderedCollection>>do: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [] in OrderedCollection(Collection)>>do:displayingProgress:every: [] in [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>on:do: [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>ensure: MorphicUIManager>>displayProgress:at:from:to:during: ProgressInitiationException>>defaultResumeValue ProgressInitiationException(Exception)>>resume ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: ByteString(String)>>displayProgressFrom:to:during: OrderedCollection(Collection)>>do:displayingProgress:every: [] in TestRunner>>basicRunSuite:do: BlockClosure>>ensure: TestRunner>>basicRunSuite:do: TestRunner>>debugSuite: TestRunner>>debug: TestRunner>>failedSelected: PluggableListMorphPlus(PluggableListMorph)>>changeModelSelection: PluggableListMorphPlus(PluggableListMorph)>>mouseUp: PluggableListMorphPlus(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableListMorphPlus(Morph)>>handleEvent: PluggableListMorphPlus(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: -- and more not shown -- |
Squeaksource, Squeak and Pharo..
|
|
How useful... This is the kind of stuff that makes me wanna shout! <complaint> I just installed Squeak 4.3 to migrate some code I had on an older
Squeak 4.x image... Loaded some of the tools I use, like ScriptManager to realize... That the newest versions are for Pharo! With references to stuff that doesn't exist in Squeak. In other words, the more commits to existing project in Squeaksource (or anywhere else where the code used
to be "Squeak friendly" and/or developed for Squeak in the first place) the Pharo people do, the less and less those projects will work with Squeak! It's just as if Volkswagen would take over the manufacturing of parts for Honda and would adapt all parts for THEIR engines... If I have a Honda, what can I do? :( With Pharo moving away from Squeak (and most other Smalltalks in fact), if we don't find a way to clearly split what is "Pharo friendly" from what is "Squeak friendly" (I resisted using the word "compatible"), where are we heading ??? </complaint> P.S. This is going to be a nightmare if we don't act before the Pharo people have "adapted" tons of stuff to *their* environment... ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) |
Re: Squeaksource, Squeak and Pharo..
|
|
On 2012-12-20 12:25 PM, Benoit St-Jean
wrote:
Yea, it's an interesting point. I hear you shouting, but who are you shouting to? You've found a problem, and somebody™ is supposed to solve if for you. Is that correct? Who? I'm on the Squeak Board and from my point of view, you're observation would be more compelling if you proposed a solution to what you've discovered. If you just say it's a problem and somebody™ should fix it, I'm not that interested. Especially when you cannot even take the time to think of a few criteria of the problem that may be used to fix it. Here's what I can tell you. Squeak infrastructure is not responsible for every project in existence. You're first solution would be to talk to the maintainers of that project. None of the maintainers of ScriptManager are Squeakers. Might that tell you something? http://www.squeaksource.com/ScriptManager The Squeak Board is in the process of looking at this issue, though. And I can say what is on the horizon. The first thing we will have is community supported packages tested regularly in images in the Squeak CI server. There will be a list of packages, a top twenty list, say, of packages that will be known to be the responsibility of the community. Now, wouldn't it be good if there was something like SqueakMap, something separate from Squeaksource and SqueakSource3, that was a Squeak-only location for packages? They you'd know that you had come to the right "app store". We're working on that too. But I don't think it will be SqueakMap, which in my opinion has run its course. So were looking at this issue. But SqueakMap is a contentious issue. Very contentious. There are those who would like to put a stick of dynamite in it. And those who get extremely incensed at even the thought. (Actually, even the word, in public, like I just did. Counting down in ... four...three ... two...oh, look!) So, we're looking at that. And in the near future, say Squeak 4.5, there will be better guidelines around these problems. You could load the same packages into the new Squeak4.3 that you loaded before. If you want the latest Squeak in addition to the latest versions of the packages, well, then I think you may need to do some work. And when the infrastructure I just described is in place, there will most certainly be packages that, all that new infrastructure notwithstanding, will be nobody's responsibility but yours and the actual package developer. Chris |
Re: Squeaksource, Squeak and Pharo..
|
|
FYI, I did post my remarks/concerns on the Squeak and Pharo mailing lists regarding this subject a year ago but it just seems like nobody read or did care. Secondly, as I said, a year ago, we should definitely have *separate* code repositories for Squeak and Pharo. I just closed Squeak 30 seconds ago, being totally fed up with packages that wouldn't load... Right now, both environments are polluting the code of the other and it's nonsense... You know the kind of horror story where version 7 (Squeak) fixes version 6 (Pharo) that now became version 8 (Pharo again) but that will be fixed as a combo of version 6 and 8 for Squeak? Can't we have something simple like the Cincom Public Repository ??? Could you commit Ruby code to the CRAN (Comprehensive R Arcive Network) ? No! You know why? Those are 2 different beasts, just like Squeak and Pharo. And seeing at which speed Pharo is moving away from "standard" (for lack of a better word) Smalltalk, this "problem will happen more and more and more. How useful is Squeak if all the code available is slowly becoming "Pharo-only friendly" ? In other words, we should setup our *own* SQUEAK ONLY repository, make sure people set a "platform target" (say Squeak 4.4 or 4.3) for migration (and tell the project owners that they should make an effort to port their code to Squeak 4.x) and start from there... Now, try to imagine a newbie who's trying to load a single package (say ODBC), connect to a database, select one row and experiment with Smalltalk... Oh, wait! ScriptLoader loadFFi doesn't work! Oh wait! I read on the wiki that I had to compile the fields for ExternalStructure by hand because of a bug... Oh wait, the ODBCEnh contains Pharo stuff... Oh wait, Package X contains references to stuff that is "Pharo only". Oh wait, I'll use this other tool... Nah, contains Pharo stuff again... I'll then use package Y then... Oh wait, what's that Zinc stuff ? Well, I guess you get the picture... Now, compare this with VisualWorks and the Cincom Public Repository... Connect, load, done. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
Re: Squeaksource, Squeak and Pharo..
|
|
On 20 December 2012 19:23, Benoit St-Jean <[hidden email]> wrote:
> FYI, I did post my remarks/concerns on the Squeak and Pharo mailing lists > regarding this subject a year ago but it just seems like nobody read or did > care. > > Secondly, as I said, a year ago, we should definitely have *separate* code > repositories for Squeak and Pharo. I just closed Squeak 30 seconds ago, > being totally fed up with packages that wouldn't load... Right now, both > environments are polluting the code of the other and it's nonsense... You > know the kind of horror story where version 7 (Squeak) fixes version 6 > (Pharo) that now became version 8 (Pharo again) but that will be fixed as a > combo of version 6 and 8 for Squeak? > > Can't we have something simple like the Cincom Public Repository ??? > > Could you commit Ruby code to the CRAN (Comprehensive R Arcive Network) ? > No! You know why? Those are 2 different beasts, just like Squeak and > Pharo. And seeing at which speed Pharo is moving away from "standard" (for > lack of a better word) Smalltalk, this "problem will happen more and more > and more. > > How useful is Squeak if all the code available is slowly becoming > "Pharo-only friendly" ? > > In other words, we should setup our *own* SQUEAK ONLY repository, make sure > people set a "platform target" (say Squeak 4.4 or 4.3) for migration (and > tell the project owners that they should make an effort to port their code > to Squeak 4.x) and start from there... No. That would be suicide. What we _should_ be doing is _talking_ to people. Keep the lines of communication open. The Pharo folk are not monsters. They do not break things to spite the Squeak community. And given sufficient reason and volunteered effort, they're more than happy to work towards making things cross platform. frank > Now, try to imagine a newbie who's trying to load a single package (say > ODBC), connect to a database, select one row and experiment with > Smalltalk... Oh, wait! ScriptLoader loadFFi doesn't work! Oh wait! I read > on the wiki that I had to compile the fields for ExternalStructure by hand > because of a bug... Oh wait, the ODBCEnh contains Pharo stuff... Oh wait, > Package X contains references to stuff that is "Pharo only". Oh wait, I'll > use this other tool... Nah, contains Pharo stuff again... I'll then use > package Y then... Oh wait, what's that Zinc stuff ? Well, I guess you get > the picture... > > Now, compare this with VisualWorks and the Cincom Public Repository... > Connect, load, done. > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ________________________________ > From: Chris Cunnington <[hidden email]> > To: [hidden email] > Sent: Thursday, December 20, 2012 1:06:36 PM > Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo.. > > On 2012-12-20 12:25 PM, Benoit St-Jean wrote: > > How useful... This is the kind of stuff that makes me wanna shout! > > <complaint> > > I just installed Squeak 4.3 to migrate some code I had on an older Squeak > 4.x image... > > Loaded some of the tools I use, like ScriptManager to realize... That the > newest versions are for Pharo! With references to stuff that doesn't exist > in Squeak. > > In other words, the more commits to existing project in Squeaksource (or > anywhere else where the code used to be "Squeak friendly" and/or developed > for Squeak in the first place) the Pharo people do, the less and less those > projects will work with Squeak! > > It's just as if Volkswagen would take over the manufacturing of parts for > Honda and would adapt all parts for THEIR engines... If I have a Honda, > what can I do? :( > > With Pharo moving away from Squeak (and most other Smalltalks in fact), if > we don't find a way to clearly split what is "Pharo friendly" from what is > "Squeak friendly" (I resisted using the word "compatible"), where are we > heading ??? > > </complaint> > > P.S. This is going to be a nightmare if we don't act before the Pharo > people have "adapted" tons of stuff to *their* environment... > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > Yea, it's an interesting point. I hear you shouting, but who are you > shouting to? You've found a problem, and somebody™ is supposed to solve if > for you. Is that correct? Who? > > I'm on the Squeak Board and from my point of view, you're observation would > be more compelling if you proposed a solution to what you've discovered. If > you just say it's a problem and somebody™ should fix it, I'm not that > interested. Especially when you cannot even take the time to think of a few > criteria of the problem that may be used to fix it. > > Here's what I can tell you. Squeak infrastructure is not responsible for > every project in existence. You're first solution would be to talk to the > maintainers of that project. None of the maintainers of ScriptManager are > Squeakers. Might that tell you something? > > http://www.squeaksource.com/ScriptManager > > > The Squeak Board is in the process of looking at this issue, though. And I > can say what is on the horizon. The first thing we will have is community > supported packages tested regularly in images in the Squeak CI server. There > will be a list of packages, a top twenty list, say, of packages that will be > known to be the responsibility of the community. > > Now, wouldn't it be good if there was something like SqueakMap, something > separate from Squeaksource and SqueakSource3, that was a Squeak-only > location for packages? They you'd know that you had come to the right "app > store". We're working on that too. But I don't think it will be SqueakMap, > which in my opinion has run its course. So were looking at this issue. But > SqueakMap is a contentious issue. Very contentious. There are those who > would like to put a stick of dynamite in it. And those who get extremely > incensed at even the thought. (Actually, even the word, in public, like I > just did. Counting down in ... four...three ... two...oh, look!) > > So, we're looking at that. And in the near future, say Squeak 4.5, there > will be better guidelines around these problems. > > You could load the same packages into the new Squeak4.3 that you loaded > before. If you want the latest Squeak in addition to the latest versions of > the packages, well, then I think you may need to do some work. And when the > infrastructure I just described is in place, there will most certainly be > packages that, all that new infrastructure notwithstanding, will be nobody's > responsibility but yours and the actual package developer. > > Chris > > > > > > > |
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Benoit St-Jean
On Thu, Dec 20, 2012 at 2:23 PM, Benoit St-Jean <[hidden email]> wrote: In other words, we should setup our *own* SQUEAK ONLY repository
Now there's an idea. Sort of like a ports tree. Colin |
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Benoit St-Jean
On 2012-12-20 2:23 PM, Benoit St-Jean
wrote:
Yes, I agree. It's a problem. And all the points you make are valid. And this time, thank you, you came up with some examples with things examples you like and would like to see. Others reading this will find that useful for the process of finding a solution. I will say this, though. Sometimes, it's not as easy as it seems. By that I mean there can be a technical solution available that people do not want to use. They just don't like it: the interface; the experience; the process, whatever. That's SqueakMap. When the SqueakMap advocate shows up the first thing he will say is: "SqueakMap solves all those problems. It does all that." And you know what, he has a point. But if people don't want to use it... You see, Benoit, the problem is less about code and about something else. But smart are people thinking about this. They want a solution too. Chris
|
Re: Squeaksource, Squeak and Pharo..
|
|
On 20 December 2012 19:31, Chris Cunnington
<[hidden email]> wrote: > On 2012-12-20 2:23 PM, Benoit St-Jean wrote: > > FYI, I did post my remarks/concerns on the Squeak and Pharo mailing lists > regarding this subject a year ago but it just seems like nobody read or did > care. > > Secondly, as I said, a year ago, we should definitely have *separate* code > repositories for Squeak and Pharo. I just closed Squeak 30 seconds ago, > being totally fed up with packages that wouldn't load... Right now, both > environments are polluting the code of the other and it's nonsense... You > know the kind of horror story where version 7 (Squeak) fixes version 6 > (Pharo) that now became version 8 (Pharo again) but that will be fixed as a > combo of version 6 and 8 for Squeak? > > Yes, I agree. It's a problem. And all the points you make are valid. And > this time, thank you, you came up with some examples with things examples > you like and would like to see. Others reading this will find that useful > for the process of finding a solution. > > I will say this, though. Sometimes, it's not as easy as it seems. By that I > mean there can be a technical solution available that people do not want to > use. They just don't like it: the interface; the experience; the process, > whatever. That's SqueakMap. When the SqueakMap advocate shows up the first > thing he will say is: "SqueakMap solves all those problems. It does all > that." And you know what, he has a point. > > But if people don't want to use it... You see, Benoit, the problem is less > about code and about something else. But smart are people thinking about > this. They want a solution too. I think SM's real problem is that everyone forgot about it. And when someone remembered it (was it Chris Muller?), it looked old and dated. The idea's sound, the code might need some love, but it _works_. Here, _today_. Not as shiny as yet another brand new idea to solve an old problem, maybe. Maybe it needs some love, and a touch of makeup. But you can go load a few packages right now into your 4.4 image. frank > Chris > > Can't we have something simple like the Cincom Public Repository ??? > > Could you commit Ruby code to the CRAN (Comprehensive R Arcive Network) ? > No! You know why? Those are 2 different beasts, just like Squeak and > Pharo. And seeing at which speed Pharo is moving away from "standard" (for > lack of a better word) Smalltalk, this "problem will happen more and more > and more. > > How useful is Squeak if all the code available is slowly becoming > "Pharo-only friendly" ? > > In other words, we should setup our *own* SQUEAK ONLY repository, make sure > people set a "platform target" (say Squeak 4.4 or 4.3) for migration (and > tell the project owners that they should make an effort to port their code > to Squeak 4.x) and start from there... > > Now, try to imagine a newbie who's trying to load a single package (say > ODBC), connect to a database, select one row and experiment with > Smalltalk... Oh, wait! ScriptLoader loadFFi doesn't work! Oh wait! I read > on the wiki that I had to compile the fields for ExternalStructure by hand > because of a bug... Oh wait, the ODBCEnh contains Pharo stuff... Oh wait, > Package X contains references to stuff that is "Pharo only". Oh wait, I'll > use this other tool... Nah, contains Pharo stuff again... I'll then use > package Y then... Oh wait, what's that Zinc stuff ? Well, I guess you get > the picture... > > Now, compare this with VisualWorks and the Cincom Public Repository... > Connect, load, done. > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ________________________________ > From: Chris Cunnington <[hidden email]> > To: [hidden email] > Sent: Thursday, December 20, 2012 1:06:36 PM > Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo.. > > On 2012-12-20 12:25 PM, Benoit St-Jean wrote: > > How useful... This is the kind of stuff that makes me wanna shout! > > <complaint> > > I just installed Squeak 4.3 to migrate some code I had on an older Squeak > 4.x image... > > Loaded some of the tools I use, like ScriptManager to realize... That the > newest versions are for Pharo! With references to stuff that doesn't exist > in Squeak. > > In other words, the more commits to existing project in Squeaksource (or > anywhere else where the code used to be "Squeak friendly" and/or developed > for Squeak in the first place) the Pharo people do, the less and less those > projects will work with Squeak! > > It's just as if Volkswagen would take over the manufacturing of parts for > Honda and would adapt all parts for THEIR engines... If I have a Honda, > what can I do? :( > > With Pharo moving away from Squeak (and most other Smalltalks in fact), if > we don't find a way to clearly split what is "Pharo friendly" from what is > "Squeak friendly" (I resisted using the word "compatible"), where are we > heading ??? > > </complaint> > > P.S. This is going to be a nightmare if we don't act before the Pharo > people have "adapted" tons of stuff to *their* environment... > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > Yea, it's an interesting point. I hear you shouting, but who are you > shouting to? You've found a problem, and somebody™ is supposed to solve if > for you. Is that correct? Who? > > I'm on the Squeak Board and from my point of view, you're observation would > be more compelling if you proposed a solution to what you've discovered. If > you just say it's a problem and somebody™ should fix it, I'm not that > interested. Especially when you cannot even take the time to think of a few > criteria of the problem that may be used to fix it. > > Here's what I can tell you. Squeak infrastructure is not responsible for > every project in existence. You're first solution would be to talk to the > maintainers of that project. None of the maintainers of ScriptManager are > Squeakers. Might that tell you something? > > http://www.squeaksource.com/ScriptManager > > > The Squeak Board is in the process of looking at this issue, though. And I > can say what is on the horizon. The first thing we will have is community > supported packages tested regularly in images in the Squeak CI server. There > will be a list of packages, a top twenty list, say, of packages that will be > known to be the responsibility of the community. > > Now, wouldn't it be good if there was something like SqueakMap, something > separate from Squeaksource and SqueakSource3, that was a Squeak-only > location for packages? They you'd know that you had come to the right "app > store". We're working on that too. But I don't think it will be SqueakMap, > which in my opinion has run its course. So were looking at this issue. But > SqueakMap is a contentious issue. Very contentious. There are those who > would like to put a stick of dynamite in it. And those who get extremely > incensed at even the thought. (Actually, even the word, in public, like I > just did. Counting down in ... four...three ... two...oh, look!) > > So, we're looking at that. And in the near future, say Squeak 4.5, there > will be better guidelines around these problems. > > You could load the same packages into the new Squeak4.3 that you loaded > before. If you want the latest Squeak in addition to the latest versions of > the packages, well, then I think you may need to do some work. And when the > infrastructure I just described is in place, there will most certainly be > packages that, all that new infrastructure notwithstanding, will be nobody's > responsibility but yours and the actual package developer. > > Chris > > > > > > > > > > |
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Colin Putney-3
Hi Colin, Yeah, your idea makes sense, somehow... But adding a layer, when it's clear that Pharo is deconstructing the "Squeak base" (its ancestor) piece by piece will make it hard. At the rate at which they are deleting "squeak stuff" in the Pharo image, we'll all spend our time coding for this "compatibility/portability" layer. Besides, can you imagine the mess that will result for projects that are cross dialect and that are already providing compatibility layers (Glorp, Seaside, etc) ??? Two layers of compatibility, really ??? To paraphrase Fleetwood Mac, "you can go your own way" I'd tell the Pharo people. I find it funny that Squeak's child (Pharo) is farther away from Squeak than VisualWorks can be these days... ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Chris Cunnington
Hi Chris, I'm sorry if I might have somehow seemed rude but I never implied that it was Squeak's Board fault in any way. Btw, English is not my first language! I really think we shouldn't consider Pharo as a Squeak fork anymore : they have their own agenda and it's clear that compatibility (a hot topic on the Pharo mailing list these days) is not a concern for them. They want their own ship, their own people, their own infrastructure, their own vision, their own way of doing things, their own tools (do you really want Nautilus for Squeak ?!?! Or Zinc ?!?!), their own destination... Whcih is clearly not the same destination as ours (Squeakers). Who's concerned by decisions taken by Cincom or Instatiations here (from a Squeak perspective)? No one, because we live in different worlds. Well, it's time to recognize the same thing with Pharo : they now live in a different galaxy than ours. It's time to do/manage/build our own things, our own way, in our own space. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Frank Shearar-3
Hi Frank, That's another problem. Let's say I'm a newbie. I quickly download a pdf, play with Colletion examples, then Date, then Integer, then Stream, etc... Now, I feel like I want to experiment... Where do I get Squeak code from? Universes? Gofer? Monticello? SqueakMap? Metacello? Squeaksource? Squeaksource 3? SmalltalkHub? Via ScriptLoader? There are sooooooooooo many references out on the web to "inform" you on how to get code that, no wonder, any newbie will give up in 5 minutes if it doesn't load... What I like about the Cincom Repository is that : 1) ONE repository, not many (or even worse, many ways) 2) the code is VisualWorks only 3) EVERYTHING is in one place, it's all there 4) process is simple : connect, load, done. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Benoit St-Jean
On Thu, Dec 20, 2012 at 2:40 PM, Benoit St-Jean <[hidden email]> wrote:
Well, I wasn't thinking of a Pharo compatibility layer, so much as a repository where we could store the "Squeak port" for packages that aren't developed natively on Squeak. (By "ports tree," I meant FreeBSD's ports system.) So, for example, the Xtreams port from VisualWorks could live there, the Seaside port from Pharo, and so on.
And of course, Frank is quite right, no technical solution like this is a substitute for communication with developers in other communities. But if we have a strategy for handling things like this, it can make that communication smoother.
Just a thought. Colin |
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Benoit St-Jean
On 20 December 2012 19:52, Benoit St-Jean <[hidden email]> wrote:
> Hi Frank, > > That's another problem. > > Let's say I'm a newbie. > > I quickly download a pdf, play with Colletion examples, then Date, then > Integer, then Stream, etc... > > Now, I feel like I want to experiment... > > Where do I get Squeak code from? > > Universes? Gofer? Monticello? SqueakMap? Metacello? Squeaksource? > Squeaksource 3? SmalltalkHub? Via ScriptLoader? There are sooooooooooo > many references out on the web to "inform" you on how to get code that, no > wonder, any newbie will give up in 5 minutes if it doesn't load... What _should_ happen, and we're not there yet, is you go to SqueakMap and, if you can't find a package listed there you hunt down the person responsible and nag them until it _is_ there. You shouldn't have know or care whether a project's hosted on SqueakSource or SS3 or GitHub. frank > What I like about the Cincom Repository is that : > > 1) ONE repository, not many (or even worse, many ways) > 2) the code is VisualWorks only > 3) EVERYTHING is in one place, it's all there > 4) process is simple : connect, load, done. > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ________________________________ > From: Frank Shearar <[hidden email]> > To: The general-purpose Squeak developers list > <[hidden email]> > Sent: Thursday, December 20, 2012 2:35:19 PM > > Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo.. > > On 20 December 2012 19:31, Chris Cunnington > <[hidden email]> wrote: >> On 2012-12-20 2:23 PM, Benoit St-Jean wrote: >> >> FYI, I did post my remarks/concerns on the Squeak and Pharo mailing lists >> regarding this subject a year ago but it just seems like nobody read or >> did >> care. >> >> Secondly, as I said, a year ago, we should definitely have *separate* code >> repositories for Squeak and Pharo. I just closed Squeak 30 seconds ago, >> being totally fed up with packages that wouldn't load... Right now, both >> environments are polluting the code of the other and it's nonsense... You >> know the kind of horror story where version 7 (Squeak) fixes version 6 >> (Pharo) that now became version 8 (Pharo again) but that will be fixed as >> a >> combo of version 6 and 8 for Squeak? >> >> Yes, I agree. It's a problem. And all the points you make are valid. And >> this time, thank you, you came up with some examples with things examples >> you like and would like to see. Others reading this will find that useful >> for the process of finding a solution. >> >> I will say this, though. Sometimes, it's not as easy as it seems. By that >> I >> mean there can be a technical solution available that people do not want >> to >> use. They just don't like it: the interface; the experience; the process, >> whatever. That's SqueakMap. When the SqueakMap advocate shows up the first >> thing he will say is: "SqueakMap solves all those problems. It does all >> that." And you know what, he has a point. >> >> But if people don't want to use it... You see, Benoit, the problem is less >> about code and about something else. But smart are people thinking about >> this. They want a solution too. > > I think SM's real problem is that everyone forgot about it. And when > someone remembered it (was it Chris Muller?), it looked old and dated. > The idea's sound, the code might need some love, but it _works_. Here, > _today_. Not as shiny as yet another brand new idea to solve an old > problem, maybe. Maybe it needs some love, and a touch of makeup. But > you can go load a few packages right now into your 4.4 image. > > frank > >> Chris >> >> Can't we have something simple like the Cincom Public Repository ??? >> >> Could you commit Ruby code to the CRAN (Comprehensive R Arcive Network) ? >> No! You know why? Those are 2 different beasts, just like Squeak and >> Pharo. And seeing at which speed Pharo is moving away from "standard" >> (for >> lack of a better word) Smalltalk, this "problem will happen more and more >> and more. >> >> How useful is Squeak if all the code available is slowly becoming >> "Pharo-only friendly" ? >> >> In other words, we should setup our *own* SQUEAK ONLY repository, make >> sure >> people set a "platform target" (say Squeak 4.4 or 4.3) for migration (and >> tell the project owners that they should make an effort to port their code >> to Squeak 4.x) and start from there... >> >> Now, try to imagine a newbie who's trying to load a single package (say >> ODBC), connect to a database, select one row and experiment with >> Smalltalk... Oh, wait! ScriptLoader loadFFi doesn't work! Oh wait! I >> read >> on the wiki that I had to compile the fields for ExternalStructure by hand >> because of a bug... Oh wait, the ODBCEnh contains Pharo stuff... Oh >> wait, >> Package X contains references to stuff that is "Pharo only". Oh wait, >> I'll >> use this other tool... Nah, contains Pharo stuff again... I'll then use >> package Y then... Oh wait, what's that Zinc stuff ? Well, I guess you >> get >> the picture... >> >> Now, compare this with VisualWorks and the Cincom Public Repository... >> Connect, load, done. >> >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> >> ________________________________ >> From: Chris Cunnington <[hidden email]> >> To: [hidden email] >> Sent: Thursday, December 20, 2012 1:06:36 PM >> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo.. >> >> On 2012-12-20 12:25 PM, Benoit St-Jean wrote: >> >> How useful... This is the kind of stuff that makes me wanna shout! >> >> <complaint> >> >> I just installed Squeak 4.3 to migrate some code I had on an older Squeak >> 4.x image... >> >> Loaded some of the tools I use, like ScriptManager to realize... That the >> newest versions are for Pharo! With references to stuff that doesn't exist >> in Squeak. >> >> In other words, the more commits to existing project in Squeaksource (or >> anywhere else where the code used to be "Squeak friendly" and/or developed >> for Squeak in the first place) the Pharo people do, the less and less >> those >> projects will work with Squeak! >> >> It's just as if Volkswagen would take over the manufacturing of parts for >> Honda and would adapt all parts for THEIR engines... If I have a Honda, >> what can I do? :( >> >> With Pharo moving away from Squeak (and most other Smalltalks in fact), if >> we don't find a way to clearly split what is "Pharo friendly" from what is >> "Squeak friendly" (I resisted using the word "compatible"), where are we >> heading ??? >> >> </complaint> >> >> P.S. This is going to be a nightmare if we don't act before the Pharo >> people have "adapted" tons of stuff to *their* environment... >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> >> >> Yea, it's an interesting point. I hear you shouting, but who are you >> shouting to? You've found a problem, and somebody™ is supposed to solve if >> for you. Is that correct? Who? >> >> I'm on the Squeak Board and from my point of view, you're observation >> would >> be more compelling if you proposed a solution to what you've discovered. >> If >> you just say it's a problem and somebody™ should fix it, I'm not that >> interested. Especially when you cannot even take the time to think of a >> few >> criteria of the problem that may be used to fix it. >> >> Here's what I can tell you. Squeak infrastructure is not responsible for >> every project in existence. You're first solution would be to talk to the >> maintainers of that project. None of the maintainers of ScriptManager are >> Squeakers. Might that tell you something? >> >> http://www.squeaksource.com/ScriptManager >> >> >> The Squeak Board is in the process of looking at this issue, though. And I >> can say what is on the horizon. The first thing we will have is community >> supported packages tested regularly in images in the Squeak CI server. >> There >> will be a list of packages, a top twenty list, say, of packages that will >> be >> known to be the responsibility of the community. >> >> Now, wouldn't it be good if there was something like SqueakMap, something >> separate from Squeaksource and SqueakSource3, that was a Squeak-only >> location for packages? They you'd know that you had come to the right "app >> store". We're working on that too. But I don't think it will be SqueakMap, >> which in my opinion has run its course. So were looking at this issue. But >> SqueakMap is a contentious issue. Very contentious. There are those who >> would like to put a stick of dynamite in it. And those who get extremely >> incensed at even the thought. (Actually, even the word, in public, like I >> just did. Counting down in ... four...three ... two...oh, look!) >> >> So, we're looking at that. And in the near future, say Squeak 4.5, there >> will be better guidelines around these problems. >> >> You could load the same packages into the new Squeak4.3 that you loaded >> before. If you want the latest Squeak in addition to the latest versions >> of >> the packages, well, then I think you may need to do some work. And when >> the >> infrastructure I just described is in place, there will most certainly be >> packages that, all that new infrastructure notwithstanding, will be >> nobody's >> responsibility but yours and the actual package developer. >> >> Chris >> >> >> >> >> >> >> >> >> >> > > > > > > |
Re: Release candidate Squeak4.4-12320 ready
|
|
In reply to this post by Frank Shearar-3
On Thu, Dec 20, 2012 at 6:05 AM, Frank Shearar <[hidden email]> wrote: * http://ftp.squeak.org/4.4/Squeak4.4-12320.tgz This doesn't solve the dirty package problem though (http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/167052.html).
I ran the following doIt in the above image: | trunk dirty |
trunk := MCRepositoryGroup default repositories detect: [:ea | ea description = 'http://source.squeak.org/trunk'].
dirty := Dictionary new. MCWorkingCopy allManagers collect:
[:ea || changes | changes := ea changesRelativeToRepository: trunk.
changes isEmpty ifFalse: [dirty at: ea put: changes]].
^ dirty It takes a while, but it gives the following list of dirty packages: Collections FlexibleVocabularies
Graphics Multilingual SMLoader ToolBuilder-Kernel Some of these are harmless, but we shouldn't ship the image without fixing at least Collections and ToolBuilder-Kernel.
Colin |
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Colin Putney-3
I would say, let's keep it simple. If it's a package that is a port from another Smalltalk dialect, the Squeak version should be in the Squeak repository. If it's a package that originates from Squeak and that other dialects are porting, let's keep the Squeak version into the Squeak repository. If it's a package that no one cares about and it's for Squeak, let's keep it into the Squeak repository. Just like the Cincom Public Repository : if it's code for VisualWorks, it's all there in ONE place. If it<s code for Squeak, it should all be in one place. Now, it's just a matter of "enhancing" our repository with package comments to say that package 1.2 for Squeak corresponds to version 3.4 of VisualWorks XStreams package. Or version 0.2 of Nautilus for Squeak is in fact a port of the Pharo 1.2 version of Nautilus. Or that AbtConverter 3.1 for Squeak is a port of AbtConverter 7.4 of VAST. But ALL the Squeak code in ONE place. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Frank Shearar-3
You know what I like about CRAN (Comprehensive R Archive Network) or RAA (Ruby Application Archive) and so many other repositories ? If I'm looking for a R library, I have to go to ONE place. If I'm looking for Ruby code, I have to go to ONE place. If I'm looking for VisualWorks code, I have to go to ONE place. What prevents us from doing the same ? ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
|
Re: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Benoit St-Jean
On 12/20/12 4:52 PM, "Benoit St-Jean" <[hidden email]> wrote: >> Universes? Gofer? Monticello? SqueakMap? Metacello? Squeaksource? >> Squeaksource 3? SmalltalkHub? Via ScriptLoader? There are sooooooooooo >> many references out on the web to "inform" you on how to get code that, no >> wonder, any newbie will give up in 5 minutes if it doesn't load... My 2 cents say you should stick to Monticello and Squeaksource 3 for now. Could easily load Gofer into Squeak (Andreas do some named Goofy , what¹s I like to see as the only way of load code) But do not dream about loading Pharo code into Squeak. No if you don¹t like tons of troubles. Which projects you use, if I could ask ? Edgar |
RE: Squeaksource, Squeak and Pharo..
|
|
In reply to this post by Frank Shearar-3
Hi All,
Does anyone have a practical solution for this problem? What would be needed to make it so that I can write my package for different versions of Squeak and Pharo? I don't know enough about the pieces involved but here is a question (I've been a bit out of the loop). If Squeak supported MetaCello and PackageInstaller would that make it easier for the Squeak Community to write code that is compatible with both systems? If I wanted to port my code to Pharo using Monticello how would I do that now? I use Monticello Configurations and loved them. Is it as easy as making an installer category and publishing a Monticello Configuration file? What do people do now (if anything)? I remember publishing some stuff on SqueakMap but don't remember how it worked now, not sure what's wrong with it either since IIRC it supports multiple versions. I think that the process to figure out how to publish was a barrier to entry (but don't quote me on that). I'm not taking sides just asking questions. All the best, Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting [hidden email] Follow Me On Twitter: @RonTeitelbaum www.3dicc.com |
Re: Squeaksource, Squeak and Pharo..
|
|
Hi guys,
Dne 20. 12. 2012 21:28, piše Ron Teitelbaum: > Does anyone have a practical solution for this problem? What would be > needed to make it so that I can write my package for different versions of > Squeak and Pharo? Solution is Metacello, where you can define exactly which version of some package runs for Squeak, which for Pharo, which for both. You can specify even for which version of Squeak or Pharo (or Gemstone) it works. And which exact versions of prerequisites. Etc etc. I'd really like that Squeak community adopt Metacello, this will solve many such problems while not breaking all bridges to the Pharo community. And vice versa! Ask Dale Henrichs (author of Metacello) for help. He is a nice guy, you can trust him :) Best regards Janko > I don't know enough about the pieces involved but here is a question (I've > been a bit out of the loop). If Squeak supported MetaCello and > PackageInstaller would that make it easier for the Squeak Community to write > code that is compatible with both systems? > > If I wanted to port my code to Pharo using Monticello how would I do that > now? I use Monticello Configurations and loved them. Is it as easy as > making an installer category and publishing a Monticello Configuration file? > What do people do now (if anything)? > > I remember publishing some stuff on SqueakMap but don't remember how it > worked now, not sure what's wrong with it either since IIRC it supports > multiple versions. I think that the process to figure out how to publish > was a barrier to entry (but don't quote me on that). > > I'm not taking sides just asking questions. > > All the best, > > Ron Teitelbaum > Head Of Engineering > 3d Immersive Collaboration Consulting > [hidden email] > Follow Me On Twitter: @RonTeitelbaum > www.3dicc.com > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |