November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3255 in pharo: It should be possible to print text from help browser to printer

by pharo＠googlecode.com

Comment #4 on issue 3255 by Torsten....(a)astares.de: It should be possible to print text from help browser to printer http://code.google.com/p/pharo/issues/detail?id=3255 Try the following: |printer| printer := TextPrinter new. printer bestColor. printer printText: 'HelloWorld' Anyone able to confirm the platforms that supports this (Linux, Mac, ...)? Its primitive: 232 (see Form>>primPrintHScale:vScale:landscape:) "On platforms that support it, this primitive prints the receiver, assumed to be a Form, to the default printer."

Nov. 22, 2010

Re: [Pharo-project] Issue 3255 in pharo: It should be possible to print text from help browser to printer

by pharo＠googlecode.com

Comment #3 on issue 3255 by Torsten....(a)astares.de: It should be possible to print text from help browser to printer http://code.google.com/p/pharo/issues/detail?id=3255 Have no mac to test. Works on Windows. No printing support in MacVM?

Nov. 22, 2010

Re: [Pharo-project] New to PHP 5.4: Traits

by StÃ©phane Ducasse

>> >> 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

Nov. 22, 2010

Re: [Pharo-project] New to PHP 5.4: Traits

by StÃ©phane Ducasse

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 > >

Nov. 22, 2010

Re: [Pharo-project] FileDirectory default is wrong in MacOS

by Mariano Martinez Peck

On Mon, Nov 22, 2010 at 9:17 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > 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. > Ok, thanks for the advice. But still, the problem with Pharo is present. My OS is case insensitive, but FileDirectory default is working like case sensittive..... > > > > > 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 > > > > > > > > > > >

Nov. 22, 2010

Re: [Pharo-project] FileDirectory default is wrong in MacOS

by StÃ©phane Ducasse

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 > > > >

Nov. 22, 2010

[Pharo-project] Issue 3278 in pharo: MCWorkingDescription better description

by pharo＠googlecode.com

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.2 New issue 3278 by stephane.ducasse: MCWorkingDescription better description http://code.google.com/p/pharo/issues/detail?id=3278 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

Nov. 22, 2010

Re: [Pharo-project] [ENH] Better MCWorkingCopy description in PharoInbox

by StÃ©phane Ducasse

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

Nov. 22, 2010

Re: [Pharo-project] Issue 3266 in pharo: Clean TextEditor

by StÃ©phane Ducasse

>>> >>> 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 >

Nov. 22, 2010

Re: [Pharo-project] New to PHP 5.4: Traits

by Michael Haupt

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

Nov. 22, 2010