I tried to install Citezen-All-onierstrasz.18 from
'http://www.squeaksource.com/Citezen' but after I hit load the hourglass just sits there (waited several minutes). I've pulled other packages successfully from squeaksource, as recently as yesterday. I'm not sure if there is some problem with squeaksource, or if it is particular to this package. The wiki indicates pharo. I'm in a 3.10 image with some additions, notably magma, and no seaside or pier. Any ideas what's going on? Ross 8 November 2009 10:42:48 am VM: unix - a SmalltalkImage Image: Squeak3.10.2 [latest update: #7179] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/ross/recipes Trusted Dir /home/ross/recipes/secure Untrusted Dir /home/ross/recipes/My Squeak [] in Semaphore>>waitTimeoutMSecs: {[self wait]} Arguments and temporary variables: anInteger: 5000 d: a Delay BlockContext>>ensure: Receiver: [] in Semaphore>>waitTimeoutMSecs: {[self wait]} Arguments and temporary variables: aBlock: [] in Semaphore>>waitTimeoutMSecs: {[d unschedule]} returnValue: nil b: nil Receiver's instance variables: sender: BlockContext>>ensure: pc: 51 stackp: 1 nargs: 0 startpc: 49 home: Semaphore>>waitTimeoutMSecs: Semaphore>>waitTimeoutMSecs: Receiver: a Semaphore() Arguments and temporary variables: anInteger: 5000 d: a Delay Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 1 HTTPSocket(OldSocket)>>waitForDataUntil: Receiver: a HTTPSocket[connected] Arguments and temporary variables: deadline: 79126549 dataArrived: false Receiver's instance variables: semaphore: a Semaphore() socketHandle: a ByteArray(147 234 227 89 0 0 0 0 72 20 84 8) readSemaphore: a Semaphore() writeSemaphore: a Semaphore() primitiveOnlySupportsOneSemaphore: false buffer: nil bufferPos: nil headerTokens: nil headers: nil responseCode: nil --- The full stack --- [] in Semaphore>>waitTimeoutMSecs: {[self wait]} BlockContext>>ensure: Semaphore>>waitTimeoutMSecs: HTTPSocket(OldSocket)>>waitForDataUntil: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - HTTPSocket>>getResponseUpTo:ignoring: [] in HTTPSocket class>>httpGetDocument:args:accept:request: {[sock := HTTPSocket new. sock connectTo: serverAddr port: connectToPort. (...]} SmallInteger(Integer)>>timesRepeat: HTTPSocket class>>httpGetDocument:args:accept:request: HTTPSocket class>>httpGet:args:accept:request: HTTPSocket class>>httpGet:args:user:passwd: MCHttpRepository>>allFileNames MCHttpRepository(MCFileBasedRepository)>>allFileNamesOrCache MCHttpRepository(MCFileBasedRepository)>>readableFileNames MCHttpRepository(MCFileBasedRepository)>>allFileNamesForVersionNamed: MCHttpRepository(MCFileBasedRepository)>>versionWithInfo:ifAbsent: MCHttpRepository(MCRepository)>>versionWithInfo: [] in MCRepositoryGroup>>versionWithInfo:ifNone: {[:ea | (ea versionWithInfo: aVersionInfo) ifNotNilDo: [:v | ^ v]]} [] in MCRepositoryGroup>>repositoriesDo: {[aBlock value: ea]} BlockContext>>on:do: [] in MCRepositoryGroup>>repositoriesDo: {[:ea | [aBlock value: ea] on: Error do: []]} Array(SequenceableCollection)>>do: MCRepositoryGroup>>repositoriesDo: MCRepositoryGroup>>versionWithInfo:ifNone: [] in MCVersionDependency>>resolve {[MCRepositoryGroup default versionWithInfo: versionInfo ifNone: []]} MCRepositoryGroup>>versionWithInfo:ifNone: MCVersionDependency>>resolve MCVersionLoader>>addDependency: [] in MCVersionLoader>>addVersion: {[:ea | self addDependency: ea]} Array(SequenceableCollection)>>do: MCVersionLoader>>addVersion: MCVersionLoader class>>loadVersion: MCVersion>>load [] in MCFileRepositoryInspector(MCVersionInspector)>>load {[self version load]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MCFileRepositoryInspector(MCVersionInspector)>>load MCFileRepositoryInspector>>load PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction PluggableButtonMorphPlus>>performAction [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m | (m containsPoint: evt cursorPoint) ifTrue: [m performAction]]} Array(SequenceableCollection)>>do: PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: PluggableButtonMorphPlus>>mouseUp: PluggableButtonMorphPlus(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorphPlus(Morph)>>handleEvent: PluggableButtonMorphPlus(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: ...etc... |
El dom, 08-11-2009 a las 10:52 -0800, [hidden email]
escribió: > I tried to install Citezen-All-onierstrasz.18 from > 'http://www.squeaksource.com/Citezen' but after I hit load the hourglass > just sits there (waited several minutes). I've pulled other packages > successfully from squeaksource, as recently as yesterday. Try Ctrl + . to see what process is hanging the image. > > I'm not sure if there is some problem with squeaksource, or if it is > particular to this package. The wiki indicates pharo. I'm in a 3.10 > image with some additions, notably magma, and no seaside or pier. Do you need Squeak for some reason? If not, just use Pharo. > > Any ideas what's going on? > Ross > > 8 November 2009 10:42:48 am > > VM: unix - a SmalltalkImage > Image: Squeak3.10.2 [latest update: #7179] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /home/ross/recipes > Trusted Dir /home/ross/recipes/secure > Untrusted Dir /home/ross/recipes/My Squeak > > [] in Semaphore>>waitTimeoutMSecs: {[self wait]} > Arguments and temporary variables: > anInteger: 5000 > d: a Delay > > BlockContext>>ensure: > Receiver: [] in Semaphore>>waitTimeoutMSecs: {[self wait]} > Arguments and temporary variables: > aBlock: [] in Semaphore>>waitTimeoutMSecs: {[d unschedule]} > returnValue: nil > b: nil > Receiver's instance variables: > sender: BlockContext>>ensure: > pc: 51 > stackp: 1 > nargs: 0 > startpc: 49 > home: Semaphore>>waitTimeoutMSecs: > > Semaphore>>waitTimeoutMSecs: > Receiver: a Semaphore() > Arguments and temporary variables: > anInteger: 5000 > d: a Delay > Receiver's instance variables: > firstLink: nil > lastLink: nil > excessSignals: 1 > > HTTPSocket(OldSocket)>>waitForDataUntil: > Receiver: a HTTPSocket[connected] > Arguments and temporary variables: > deadline: 79126549 > dataArrived: false > Receiver's instance variables: > semaphore: a Semaphore() > socketHandle: a ByteArray(147 234 227 89 0 0 0 0 72 20 84 8) > readSemaphore: a Semaphore() > writeSemaphore: a Semaphore() > primitiveOnlySupportsOneSemaphore: false > buffer: nil > bufferPos: nil > headerTokens: nil > headers: nil > responseCode: nil > > > --- The full stack --- > [] in Semaphore>>waitTimeoutMSecs: {[self wait]} > BlockContext>>ensure: > Semaphore>>waitTimeoutMSecs: > HTTPSocket(OldSocket)>>waitForDataUntil: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > HTTPSocket>>getResponseUpTo:ignoring: > [] in HTTPSocket class>>httpGetDocument:args:accept:request: {[sock := > HTTPSocket new. sock connectTo: serverAddr port: connectToPort. (...]} > SmallInteger(Integer)>>timesRepeat: > HTTPSocket class>>httpGetDocument:args:accept:request: > HTTPSocket class>>httpGet:args:accept:request: > HTTPSocket class>>httpGet:args:user:passwd: > MCHttpRepository>>allFileNames > MCHttpRepository(MCFileBasedRepository)>>allFileNamesOrCache > MCHttpRepository(MCFileBasedRepository)>>readableFileNames > MCHttpRepository(MCFileBasedRepository)>>allFileNamesForVersionNamed: > MCHttpRepository(MCFileBasedRepository)>>versionWithInfo:ifAbsent: > MCHttpRepository(MCRepository)>>versionWithInfo: > [] in MCRepositoryGroup>>versionWithInfo:ifNone: {[:ea | (ea > versionWithInfo: aVersionInfo) ifNotNilDo: [:v | ^ v]]} > [] in MCRepositoryGroup>>repositoriesDo: {[aBlock value: ea]} > BlockContext>>on:do: > [] in MCRepositoryGroup>>repositoriesDo: {[:ea | [aBlock value: ea] > on: Error do: []]} > Array(SequenceableCollection)>>do: > MCRepositoryGroup>>repositoriesDo: > MCRepositoryGroup>>versionWithInfo:ifNone: > [] in MCVersionDependency>>resolve {[MCRepositoryGroup default > versionWithInfo: versionInfo ifNone: []]} > MCRepositoryGroup>>versionWithInfo:ifNone: > MCVersionDependency>>resolve > MCVersionLoader>>addDependency: > [] in MCVersionLoader>>addVersion: {[:ea | self addDependency: ea]} > Array(SequenceableCollection)>>do: > MCVersionLoader>>addVersion: > MCVersionLoader class>>loadVersion: > MCVersion>>load > [] in MCFileRepositoryInspector(MCVersionInspector)>>load {[self version > load]} > BlockContext>>ensure: > CursorWithMask(Cursor)>>showWhile: > MCFileRepositoryInspector(MCVersionInspector)>>load > MCFileRepositoryInspector>>load > PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction > PluggableButtonMorphPlus>>performAction > [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m | (m > containsPoint: evt cursorPoint) ifTrue: [m performAction]]} > Array(SequenceableCollection)>>do: > PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: > PluggableButtonMorphPlus>>mouseUp: > PluggableButtonMorphPlus(Morph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > PluggableButtonMorphPlus(Morph)>>handleEvent: > PluggableButtonMorphPlus(Morph)>>handleFocusEvent: > [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. > ActiveEvent := anEvent. result := focusHolder han...]} > [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} > BlockContext>>on:do: > PasteUpMorph>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > ...etc... > Miguel Cobá http://miguel.leugim.com.mx |
On 11/8/09 9:14 PM, "Miguel Enrique Cobá Martinez" <[hidden email]> wrote: > Do you need Squeak for some reason? If not, just use Pharo. This kind of mail UPSET me. If you wish be lost in the fog of boredom and you only interest is Web, well go Pharo (or PHP or Perl or Python) If as me you think Squeak have lots more , stay here. I don't ask you join us, but please don't fight against us. Edgar |
El lun, 09-11-2009 a las 08:09 -0200, Edgar J. De Cleene escribió:
> > > On 11/8/09 9:14 PM, "Miguel Enrique Cobá Martinez" <[hidden email]> > wrote: > > > Do you need Squeak for some reason? If not, just use Pharo. > > This kind of mail UPSET me. Too bad for you then. > > If you wish be lost in the fog of boredom and you only interest is Web, well > go Pharo (or PHP or Perl or Python) As most of the lately attention to squeak is. Lets be serious, there is a tiny market for pure Squeak or desktop apps right now, no matter how good the technology is. > > If as me you think Squeak have lots more , stay here. For academic purposes I agree, in fact it is really wonderful the things you found on squeak but, squeak isn't the only source of innovation. - Squeak loudly promotes OODBs like magma but see the current times. Non-relational and non-object-oriented databases are the way to go for quite a few applications. No matter how good the OODBs are. - That you can use the Squeak to teach children all around the world, marvelous. Really marvelous, but my kids need real food right now and the webapps are bringing food to my table. - You like Squeak a lot, great, I like to have a tool to sell software or services to people willing to spend a few bucks on them, great for me. And no, I didn't say hey, don't use squeak, doesn't work, is bad, it is the plage. No. I said: > Do you need Squeak for some reason? If not, just use Pharo. An honest questions, if he needs squeak then well try to fix the problem for Squeak. If he doesn't need squeak, then why lose time, use Pharo and get *the real problem in his hand* solved and go on. Cheers. > > I don't ask you join us, but please don't fight against us. Sorry but you are the one fighting. > > Edgar > > > -- Miguel Cobá http://miguel.leugim.com.mx |
In reply to this post by Ross Boylan-2
On Sun, 2009-11-08 at 10:52 -0800, [hidden email] wrote:
> I tried to install Citezen-All-onierstrasz.18 from > 'http://www.squeaksource.com/Citezen' but after I hit load the hourglass > just sits there (waited several minutes). I've pulled other packages > successfully from squeaksource, as recently as yesterday. For the record, the problem is cleared up now. I assume the cause was the hang-up of squeaksource reported by Nicolas. I prefer to use squeak because getting magma going under pharo has its own set of challenges--I'm not even sure I ever got it to work. magma only recently added pharo support, so things are probably more likely to go wrong there. Finally, I'm not crazy about forks and want to help the mainline stay healthy. Ross |
El mar, 10-11-2009 a las 12:02 -0800, Ross Boylan escribió:
> On Sun, 2009-11-08 at 10:52 -0800, [hidden email] wrote: > > I tried to install Citezen-All-onierstrasz.18 from > > 'http://www.squeaksource.com/Citezen' but after I hit load the hourglass > > just sits there (waited several minutes). I've pulled other packages > > successfully from squeaksource, as recently as yesterday. > For the record, the problem is cleared up now. I assume the cause was > the hang-up of squeaksource reported by Nicolas. > > I prefer to use squeak because getting magma going under pharo has its > own set of challenges--I'm not even sure I ever got it to work. Umm, I haven't had any problem and I am using it daily on production. What problem do you have to got it work on Pharo? > magma > only recently added pharo support, so things are probably more likely to > go wrong there. That is a subjective opinion. As said before I haven't had any problem with magma on pharo. > Finally, I'm not crazy about forks and want to help the > mainline stay healthy. I prefer to use PharoCore for deployment and not worry about trimming a squeak image when loading several images on production. The squeak stable image is to big, and you must update it and then trimming it. That is not the case with PharoCore. In it I just load the packages I want and nothing else. Perfect for deployment. Cheers PS. to the "against-recommending-pharo" souls, this is not a pharo advertisement, just I think that Magma is as stable and solid on Pharo as is on Squeak, no matter its short life. > > Ross > > -- Miguel Cobá http://miguel.leugim.com.mx |
Miguel Enrique Cobá Martinez wrote:
> I prefer to use PharoCore for deployment and not worry about trimming a > squeak image when loading several images on production. The squeak > stable image is to big, and you must update it and then trimming it. Out of curiosity, what have you been trimming in the past for your production deployments? > PS. to the "against-recommending-pharo" souls, this is not a pharo > advertisement, just I think that Magma is as stable and solid on Pharo > as is on Squeak, no matter its short life. I think it may be helpful to phrase your comments a bit more carefully. Keep in mind that the split between Pharo and Squeak has left just as many people wounded here as it has in the Pharo world. There is no need to rub it in every time you post here. A bit caution is useful since you don't know the history and the individuals involved. Cheers, - Andreas |
In reply to this post by Miguel Cobá
On Tue, 2009-11-10 at 14:11 -0600, Miguel Enrique Cobá Martinez wrote:
> Umm, I haven't had any problem and I am using it daily on production. > What problem do you have to got it work on Pharo? I don't recall the details, though they are probably in the pharo and magma archives. > > > magma > > only recently added pharo support, so things are probably more > likely to > > go wrong there. > > That is a subjective opinion. As said before I haven't had any problem > with magma on pharo. While no one can predict the future, my opinion has some basis in what I think are generally accepted software principles. magma has been developed with squeak and the maintainer has stated that he plans to continue that way. The general principle is "software will be more likely to work well on its native/development platforem." This morning the magma list had a report that a recent pharo change had broken magma (slightly), with the maintainer indicating he needs some help in dealing with such changes now and in the future. Ross |
On Tue, 2009-11-10 at 13:21 -0800, Ross Boylan wrote:
> > Umm, I haven't had any problem and I am using it daily on > production. > > What problem do you have to got it work on Pharo? > I don't recall the details, though they are probably in the pharo and > magma archives. In fairness, I should add I've had quite a few problems getting things working under squeak (again, in the archives). Quite a few of those only arise if one wants to run the test suite. Some of the others just arose from documentation gaps which have since been fixed. As a practical matter, I have been jumping back and forth between pharo and squeak, and various flavors of squeak (3.9 vs 3.10) to get various things (not just magma). For seaside, the principle to prefer the development platform favors pharo. Of course, for seaside + magma one has 2 different development platforms, which makes choosing a little difficult :) |
In reply to this post by Andreas.Raab
El mar, 10-11-2009 a las 12:22 -0800, Andreas Raab escribió:
> Miguel Enrique Cobá Martinez wrote: > > I prefer to use PharoCore for deployment and not worry about trimming a > > squeak image when loading several images on production. The squeak > > stable image is to big, and you must update it and then trimming it. > > Out of curiosity, what have you been trimming in the past for your > production deployments? I don't remember exactly but they included sound related ones like nebraska, tests, squeak map, sunit, a lot of morphic extras and complete categories that my code didn't use. A lot of trial and test in order to not break anything. > > > PS. to the "against-recommending-pharo" souls, this is not a pharo > > advertisement, just I think that Magma is as stable and solid on Pharo > > as is on Squeak, no matter its short life. > > I think it may be helpful to phrase your comments a bit more carefully. > Keep in mind that the split between Pharo and Squeak has left just as > many people wounded here as it has in the Pharo world. There is no need > to rub it in every time you post here. A bit caution is useful since you > don't know the history and the individuals involved. Fair enough. > > Cheers, > - Andreas > -- Miguel Cobá http://miguel.leugim.com.mx |
In reply to this post by Andreas.Raab
2009/11/10 Andreas Raab <[hidden email]>:
> Miguel Enrique Cobá Martinez wrote: >> >> I prefer to use PharoCore for deployment and not worry about trimming a >> squeak image when loading several images on production. The squeak >> stable image is to big, and you must update it and then trimming it. > > Out of curiosity, what have you been trimming in the past for your > production deployments? > >> PS. to the "against-recommending-pharo" souls, this is not a pharo >> advertisement, just I think that Magma is as stable and solid on Pharo >> as is on Squeak, no matter its short life. > > I think it may be helpful to phrase your comments a bit more carefully. Keep > in mind that the split between Pharo and Squeak has left just as many people > wounded here as it has in the Pharo world. There is no need to rub it in > every time you post here. A bit caution is useful since you don't know the > history and the individuals involved. > +1 i want to see a success for both Squeak and Pharo (!!SERIOUSLY!!). I don't see much barriers why they could not coexist peacefully and exchange the ideas. But if we start agitating people, like Miguel does, there are less chances to have a peaceful coexistance, and maybe Miguel don't realizing that he does more damage to Pharo by agitating people to switch on it, than any potential benefit, because there always other people who potentially would consider to contribute to Pharo, but don't like the attitude how people like Miguel treating Squeak. People choosing the platform to work with for own reasons, lets just respect their choice. > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. |
El mié, 11-11-2009 a las 00:08 +0200, Igor Stasenko escribió:
> 2009/11/10 Andreas Raab <[hidden email]>: > > Miguel Enrique Cobá Martinez wrote: > >> > >> I prefer to use PharoCore for deployment and not worry about trimming a > >> squeak image when loading several images on production. The squeak > >> stable image is to big, and you must update it and then trimming it. > > > > Out of curiosity, what have you been trimming in the past for your > > production deployments? > > > >> PS. to the "against-recommending-pharo" souls, this is not a pharo > >> advertisement, just I think that Magma is as stable and solid on Pharo > >> as is on Squeak, no matter its short life. > > > > I think it may be helpful to phrase your comments a bit more carefully. Keep > > in mind that the split between Pharo and Squeak has left just as many people > > wounded here as it has in the Pharo world. There is no need to rub it in > > every time you post here. A bit caution is useful since you don't know the > > history and the individuals involved. > > > > +1 > > i want to see a success for both Squeak and Pharo (!!SERIOUSLY!!). I > don't see much barriers why they could not coexist peacefully and > exchange the ideas. But if we start agitating people, like Miguel > does, there are less chances to have a peaceful coexistance, and maybe > Miguel don't realizing that he does more damage to Pharo by agitating > people to switch on it, than > any potential benefit, because there always other people who > potentially would consider to contribute to Pharo, but don't like the > attitude how people like Miguel treating Squeak. WTF are you saying. I am not against Squeak but I also promote Pharo for my own personal views. But from that to bash squeak there is a big gap. Regarding the "attitude" you talk about. I put the PS in the reply because of the reply of Edgar in http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140726.html was very loudly about a simple and honest question So I replied in http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140732.html And no, I didn't say hey, don't use squeak, doesn't work, is bad, it is the plage[sic]. No. I said: > Do you need Squeak for some reason? If not, just use Pharo. An honest questions, if he needs squeak then well try to fix the problem for Squeak. If he doesn't need squeak, then why lose time, use Pharo and get *the real problem in his hand* solved and go on. Cheers. > > I don't ask you join us, but please don't fight against us. Sorry but you are the one fighting. > > Edgar > > So, man don't do this thread more flaming that is already. I have accepted the Andreas' advice about carefully wording the posts but don't accuse me of this "attitude how people like Miguel treating Squeak." > > People choosing the platform to work with for own reasons, lets just > respect their choice. > Again, I never said that _should_ or _must_ change to Pharo, only asked if he needed Squeak for some specific reason or package. If not, maybe he could just use Pharo and continue working in his app/demo/setup whatever. Puf! And I am the one with the attitude! Yeah! -- Miguel Cobá http://miguel.leugim.com.mx |
2009/11/11 Miguel Enrique Cobá Martinez <[hidden email]>:
> El mié, 11-11-2009 a las 00:08 +0200, Igor Stasenko escribió: >> 2009/11/10 Andreas Raab <[hidden email]>: >> > Miguel Enrique Cobá Martinez wrote: >> >> >> >> I prefer to use PharoCore for deployment and not worry about trimming a >> >> squeak image when loading several images on production. The squeak >> >> stable image is to big, and you must update it and then trimming it. >> > >> > Out of curiosity, what have you been trimming in the past for your >> > production deployments? >> > >> >> PS. to the "against-recommending-pharo" souls, this is not a pharo >> >> advertisement, just I think that Magma is as stable and solid on Pharo >> >> as is on Squeak, no matter its short life. >> > >> > I think it may be helpful to phrase your comments a bit more carefully. Keep >> > in mind that the split between Pharo and Squeak has left just as many people >> > wounded here as it has in the Pharo world. There is no need to rub it in >> > every time you post here. A bit caution is useful since you don't know the >> > history and the individuals involved. >> > >> >> +1 >> >> i want to see a success for both Squeak and Pharo (!!SERIOUSLY!!). I >> don't see much barriers why they could not coexist peacefully and >> exchange the ideas. But if we start agitating people, like Miguel >> does, there are less chances to have a peaceful coexistance, and maybe >> Miguel don't realizing that he does more damage to Pharo by agitating >> people to switch on it, than >> any potential benefit, because there always other people who >> potentially would consider to contribute to Pharo, but don't like the >> attitude how people like Miguel treating Squeak. > > WTF are you saying. > > I am not against Squeak but I also promote Pharo for my own personal > views. But from that to bash squeak there is a big gap. > > Regarding the "attitude" you talk about. I put the PS in the reply > because of the reply of Edgar in > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140726.html > > was very loudly about a simple and honest question > > So I replied in > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140732.html > > > And no, I didn't say hey, don't use squeak, doesn't work, is bad, it is > the plage[sic]. No. I said: > >> Do you need Squeak for some reason? If not, just use Pharo. > > An honest questions, if he needs squeak then well try to fix the problem > for Squeak. If he doesn't need squeak, then why lose time, use Pharo and > get *the real problem in his hand* solved and go on. > Wrong. The more correct would be "use Pharo and get another, different problem at hand". And its nothing to do with fact that Pharo is better or worse than Squeak, this is the nature of things, when forks each progressing in own direction. >From that perspective your proposal is bad & blatant. That's why i said - respect people choice. > Cheers. > > > >> >> I don't ask you join us, but please don't fight against us. > > Sorry but you are the one fighting. > >> >> Edgar >> >> > > > So, man don't do this thread more flaming that is already. I have > accepted the Andreas' advice about carefully wording the posts but don't > accuse me of this "attitude how people like Miguel treating Squeak." > > > > >> >> People choosing the platform to work with for own reasons, lets just >> respect their choice. >> > > Again, I never said that _should_ or _must_ change to Pharo, only asked > if he needed Squeak for some specific reason or package. If not, maybe > he could just use Pharo and continue working in his app/demo/setup > whatever. > > Puf! And I am the one with the attitude! Yeah! > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > -- Best regards, Igor Stasenko AKA sig. |
El mié, 11-11-2009 a las 00:52 +0200, Igor Stasenko escribió:
> >> Do you need Squeak for some reason? If not, just use Pharo. > > > > An honest questions, if he needs squeak then well try to fix the problem > > for Squeak. If he doesn't need squeak, then why lose time, use Pharo and > > get *the real problem in his hand* solved and go on. > > > > Wrong. The more correct would be "use Pharo and get another, different > problem at hand". > And its nothing to do with fact that Pharo is better or worse than > Squeak, this is the nature of things, when forks each progressing in > own direction. > >From that perspective your proposal is bad & blatant. That's why i > said - respect people choice. > But nobody is forcing him to use Pharo, just that, as in other reply Torsten said, the Citezen package has been tested on Pharo: >From the wiki of the Citezen page: Package organization Quick pharo install: Installer ss project: 'Citezen'; install: 'Citezen-Loader' and the *the real problem in his hand* it appeared, I realize now, to point to Squeak, but I was refering to the application he was trying to build. That is what he should focus effort and not in trying to chase the cause of the problem when trying to load Citezen on Squeak. So, one more time I didn't bash Squeak just asked if he needed Squeak for something indispensable to his project so that if not, he could just use Pharo and continue building his own project. I will not discuss more this topic. -- Miguel Cobá http://miguel.leugim.com.mx |
In reply to this post by Ross Boylan
> This morning the magma list had a report that a recent pharo change had
> broken magma (slightly), with the maintainer indicating he needs some > help in dealing with such changes now and in the future. I think even with "(slightly)" your words are (slightly) too strong. :) Perhaps actually MY words in the original post were too strong too. It's just a Monticello informative "warning" Ross, indicating three extension methods for serializing/materializing the global EventSensor will not be loaded. 99% of applications would not ever want to try to serialize that, so it won't be a real problem for them. Regards, Chris |
On Wed, 2009-11-11 at 09:54 -0600, Chris Muller wrote:
> > This morning the magma list had a report that a recent pharo change had > > broken magma (slightly), with the maintainer indicating he needs some > > help in dealing with such changes now and in the future. > > I think even with "(slightly)" your words are (slightly) too strong. > :) Perhaps actually MY words in the original post were too strong > too. > > It's just a Monticello informative "warning" Ross, indicating three > extension methods for serializing/materializing the global EventSensor > will not be loaded. > > 99% of applications would not ever want to try to serialize that, so > it won't be a real problem for them. > > Regards, > Chris > sensor, but that with the rename it might get persisted as part of an object graph, with weird results if it ever came back from the database into, e.g., a different image (or maybe even the same image). Equivalently, I thought the methods on EventSensor kept it from being persisted, and that the new InputEventSensor (?) in pharo will lack such protection. My understanding may well be incorrect. Ross |
Free forum by Nabble | Edit this page |