- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3266 in pharo: Clean TextEditor
by StÃ©phane Ducasse Nov. 22, 2010

Nov. 22, 2010

> >>>> ...k that we can build something on simpleMorphic, >>> Why? That would be a huge disappointment. >>> >> >> so it means that we should - throw/redo polymorph extensions (because even if some code of polymorph sucks because gary did it to turn around morphic this is still the best look we have) >> > > Yes. This is a good opportunity to make it better. this is not that I'm against but **my** plate is more than full. >> - clean again all the preferences >> > > Yes. Maybe a 3 hour job. May be. >> - clean again all the MVC dependencies.... >> FillInTheBlank? PopUpMenu? > SimpleMorphic doesn't include any MVC bits or dependency. > >> Since I do not have the know-how this is why I wrote the next paragraph: >> > > Well, that doesn't stop Mariano from fighting the deepest internals of the VM... Developing any needed know-how in the Pharo community will ensure that Pharo will survive any technical difficulties that might arise in any part of the system. yes this is the idea. And we should do it but again my plate is full. > >>>> what we can do is look at the kernel and see how the changes can be applied to Morphic. But may be I'm wrong. >>>> Tell me what you think. >>>> What is clear is that I would like to have the Sophie evtn hierarchy because we will start cleaning event soon internally. >>>> Stef > > Cheers, > Juan Vuletich >

2 1

Re: [Pharo-project] New to PHP 5.4: Traits
by StÃ©phane Ducasse Nov. 22, 2010

Nov. 22, 2010

really really excellent! On Nov 21, 2010, at 12:22 PM, jaayer wrote: > http://simas.posterous.com/new-to-php-54-traits > >

5 5

Re: [Pharo-project] [ENH] Better MCWorkingCopy description in PharoInbox
by StÃ©phane Ducasse Nov. 22, 2010

Nov. 22, 2010

thanks berhnard :) Nice to hear about you. Can you sign the license? :). > Author: BernhardPieber > Time: 21 November 2010, 6:51:13 pm > UUID: 8ffedd96-5c55-470b-a2a0-fe81da9dd12a > Ancestors: Monticello-StephaneDucasse.498 > > - Changed MCWorkingCopy description so that the package name is not duplicated when, e.g. Kernel (StephaneDucasse.799) instead of Kernel (Kernel-StephaneDucasse.799). This makes the Monticello Browser easier to use. > > Enjoy, > Bernhard > > P.S. I read http://pharo-project.org/community/issue-tracking but I am still not sure if adding an issue to the tracker is mandatory in such a case. always! this is like a giant todo and integration list. Things that are not in there are ***lost*** not because we do it on purpose but just because we have busy. http://code.google.com/p/pharo/issues/detail?id=3278

2 1

[Pharo-project] Cannot upgrade my pharo-core 1.2 'tracking' image to #12234
by Sven Van Caekenberghe Nov. 22, 2010

Nov. 22, 2010

This is probably not very important, but I cannot upgrade my pharo-core 1.2 'tracking' image to #12234. This image started a long time ago as #12123. THERE_BE_DRAGONS_HERE MessageNotUnderstood: receiver of "characterBlockForIndex:" is nil 21 November 2010 4:03:32 pm VM: Mac OS - intel - 1065 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35] 30.0 Image: Pharo1.2a [Latest update: #12242] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/sven/apps/Smalltalk/Pharo/Pharo-1.2 Trusted Dir /foobar/tooBar/forSqueak/bogus/ Untrusted Dir /foobar/tooBar/forSqueak/bogus/ UndefinedObject(Object)>>doesNotUnderstand: #characterBlockForIndex: Receiver: nil Arguments and temporary variables: aMessage: characterBlockForIndex: 17441 exception: MessageNotUnderstood: receiver of "characterBlockForIndex:" is nil resumeValue: nil Receiver's instance variables: nil SmalltalkEditor(TextEditor)>>markIndex: Receiver: a SmalltalkEditor Arguments and temporary variables: Anybody else seen this ? I guess I will have to start over now ? Sven

2 2

Re: [Pharo-project] Issue 3266 in pharo: Clean TextEditor
by StÃ©phane Ducasse Nov. 22, 2010

Nov. 22, 2010

>>> >>> We should get in the sophie events hierarchy. no ? >>>> >>> It depends of the amount of work it would requires... >>> what about working on SimpleMorphic for that ? >>> >> >> I do not think that we can build something on simpleMorphic, > > Why? That would be a huge disappointment. so it means that we should - throw/redo polymorph extensions (because even if some code of polymorph sucks because gary did it to turn around morphic this is still the best look we have) - clean again all the preferences - clean again all the MVC dependencies.... Since I do not have the know-how this is why I wrote the next paragraph: >> what we can do is look at the kernel and see how the changes can be applied to Morphic. But may be I'm wrong. >> Tell me what you think. >> What is clear is that I would like to have the Sophie evtn hierarchy because we will start cleaning event soon internally. >> Stef > > Cheers, > Juan Vuletich >

2 1

Re: [Pharo-project] New to PHP 5.4: Traits
by StÃ©phane Ducasse Nov. 22, 2010

Nov. 22, 2010

>> >> On 21 Nov 2010, at 21:47, jaayer wrote: >>> Excellent that other, lesser languages like PHP, Perl 6 and Scala have already adopted and standardized Traits while the reactionaries in the Smalltalk community still resist doing the same? >> Ignoring all the sarcasm in that comment: >> I don't see any form of standardization here. I am not aware that any of the other existing PHP implementations has picked up Traits so far. > > PHP has no standard; the implementation is the standard, and Traits are being added to the implementation, hence, "standardization." My point remains; other languages are or have already adopted Traits while the Smalltalk community, from which the concept sprang, continues to drag its heels after nearly a decade since their introduction. > >> And well, it is about 3 years from the first implementation to a first release in an official alpha version of PHP. There is still a loooong way to go... > > No, there isn't, at least not compared with the rate of Smalltalk's adoption of Traits. Face it. There are just too many Smalltalkers who seem to think the language is a complete revelation that no mortal has the right to amend. Other languages can grow to accommodate new features; Smalltalk, which went through a number major revisions in the 70s at PARC, remains frozen in the amber of 1980. :) You are somehow right :). Now some points if you want to help: - I would love to have more support for traits in pharo - using them - improving tool support - revisiting their implementation: this is on my todo since andreas (with a certain marketing effect) "cleaned" the version of squeak. - one question there is can we make traits pluggable on top of the core and does it make sense. - we want other features like modules but but but but but but but but but we want to have the time to work and try out ideas (this is 8 years - yes I'm slow that we started with classboxes - and classboxes does not look like the solution) - now the first step in that direction that we started in 2002 (but people did not understand it :)) was to clean all the smalltalk reference - now we are working on making sure that we can have multiple systemDictionaries side by side it will support not only module design exploration but - OOPAL bootstrap - atomic loading (like in VW) - Moose analysis (ie Moose/pharo1.1 should be able to analyse Moose/pharo1.3 unstable) - remote debugging/development Now my problem is time. So if people want to help please contact us and we could have a lot of fun. stef

1 0

Re: [Pharo-project] New to PHP 5.4: Traits
by StÃ©phane Ducasse Nov. 22, 2010

Nov. 22, 2010

for the record we know that and our traits are not the same as we mentioned in our paper. We went back on pre self traits of 1981! So I'm not even sure that self papers refers to this work. stef On Nov 22, 2010, at 6:43 AM, Michael Haupt wrote: > > > Am 21.11.2010 um 22:53 schrieb jaayer <jaayer(a)zoho.com>: >> ... the Smalltalk community, from which the concept sprang, ... > > Self, right? And "Self includes: Smalltalk". ;-) > > Best, > > Michael > >

1 0

Nov. 22, 2010

On Nov 22, 2010, at 12:59 AM, Mariano Martinez Peck wrote: > H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so... > > Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat). you have but don't do that you may get a lot of trouble. Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you fucked up. So if you are ready to not interact with other people change else keep it the way it is. I got problem because damien in the past changed it and interacted with me. > > thanks > > mariano > > On Mon, Nov 22, 2010 at 12:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Mariano, > > Dumb question: what file system is in use? I sometimes get surprised with case insensitivity on Linux when using shared media with Microsoft file systems. From the looks of things, that is probably _not_ your problem, but it's worth ruling out. > > Bill > > > >

2 1

[Pharo-project] FileDirectory default is wrong in MacOS
by Mariano Martinez Peck Nov. 21, 2010

Nov. 21, 2010

Hi. The simplest way to find the problem (if my case it was muuuch more than this), I found the following: MacOS is case insensitive (I've just figure it out). Since it is a UNIX at the end, I thought it was case sensitive, but it seems it is not. Now, suppose that in the directory where my image is, I have the file called 'zaraza'. If I evaluate this: (FileDirectory default fileOrDirectoryExists: 'zaraza') ->>>> true I should get true. And the same with: (FileDirectory default fileOrDirectoryExists: 'ZARAZA') ->>>> false But....I get false instead of true. Which is wrong in Mac OS. The problem is that FileDirectory default -----> UnixFileDirectory And this is because FileDirectory class >> activeDirectoryClass "Return the concrete FileDirectory subclass for the platform on which we are currently running." FileDirectory allSubclasses do: [:class | class isActiveDirectoryClass ifTrue: [^ class]]. that loop answers UnixFileDirectory. This is because: nixFileDirectory class >> isActiveDirectoryClass "Does this class claim to be that properly active subclass of FileDirectory for this platform? Default test is whether the primPathNameDelimiter matches the one for this class. Other tests are possible" ^self pathNameDelimiter = self primPathNameDelimiter answers true. But anyway, why MacFileDirectory class >> isActiveDirectoryClass answers false? If we see: MacFileDirectory class >> isActiveDirectoryClass ^ super isActiveDirectoryClass and: [(Smalltalk getSystemAttribute: 1201) isNil or: [(Smalltalk getSystemAttribute: 1201) asNumber <= 31]] (Smalltalk getSystemAttribute: 1201 -> '255' So.....my questions are: 1) Should it answer Unix one, or MacOS? I guess than MacOS, and if it is unix, then we have to solve the kind of problem I have 2) Why (Smalltalk getSystemAttribute: 1201 -> '255' 3) Why not using "Smalltalk platformName" to detect which FileDirectory to use?? Thanks Mariano

3 3

[Pharo-project] [update 1.2] #12250
by Marcus Denker Nov. 21, 2010

Nov. 21, 2010

12250 ----- Issue 3270: fix xor: to work with blocks and booleans Issue 3277: [FIX] Replace #& in Socket with #and: to save #isConnected send Issue 3180: Failing Tests SUnit -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0