- Pharo-dev - lists.pharo.org

Re: [Pharo-project] call for hypercool fonts configuration

by Hilaire Fernandes

Yes, anythinks related to look'nd feel and overal design in Pharo could help a lot to make people to LOVE Pharo or to RUN AWAY. Regarding fonts, I found myself sharing the point previously expressed there: -Dejavu Sans for all but code -Code with Dedavu mono The issue about Freetype efficiency, related to submorph damage code related previsouly, is of equal importance. If the user experience is ungood -- slowness -- people will RUN AWAY. 2009/5/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > on one hand we should have a good default for fonts - default means ok > for license and > work on platforms.... > > Now I would LOVE to get a list of cool combination of fonts even if > they are proprietary. > > So I hope that I woke the designer in you :) > Send snippets in the following forms that we can impress girls :) > > > font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. > codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. > titleFont := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. > > Preferences setListFontTo: font. > Preferences setMenuFontTo: font. > Preferences setCodeFontTo: codeFont. > Preferences setButtonFontTo: font. > Preferences setSystemFontTo: font. > Preferences setWindowTitleFontTo: titleFont. > > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

May 21, 2009

[Pharo-project] About "external" pharo code

by StÃ©phane Ducasse

Hi guys I would like to have a discussion with you. What do we do with the code like the excellent PlotMorph that do not have its own package. Do we create a package for it? Do we create a PharoAddOnsOrphans? Ideally I would like that people can maintain improve such packages as well as the ones we may remove (ledMorph and others). Stef

May 21, 2009

[Pharo-project] Possible PhD grant for European

by StÃ©phane Ducasse

Hi all I just learned that I could apply for a PhD grant for european student (non-french). So if you are interested by research on reengineering or language design please contact me. Stef

May 21, 2009

[Pharo-project] call for hypercool fonts configuration

by StÃ©phane Ducasse

Hi guys on one hand we should have a good default for fonts - default means ok for license and work on platforms.... Now I would LOVE to get a list of cool combination of fonts even if they are proprietary. So I hope that I woke the designer in you :) Send snippets in the following forms that we can impress girls :) font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. titleFont := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. Preferences setListFontTo: font. Preferences setMenuFontTo: font. Preferences setCodeFontTo: codeFont. Preferences setButtonFontTo: font. Preferences setSystemFontTo: font. Preferences setWindowTitleFontTo: titleFont. Stef

May 21, 2009

Re: [Pharo-project] Symbol>>value:value:

by StÃ©phane Ducasse

I would be in favor of having value: value: on symbol and get rid of value on Object Because this is really cool to write #( 1 2 3) collect: #abs On May 20, 2009, at 4:01 PM, Tudor Girba wrote: > Hi, > > (I apologize for the length of this email, but I did not know how to > write it shorter) > > My reasons for Symbol>>value: and similar selectors are as follows. > > A Symbol is already used for several things, like a key in an identity > dictionary. But it is also used for parameterizing a mapping to a > piece of behavior via a #symbol stored in a selector instance > variable. Later on, this behavior is invoked as: > > receiver perform: selector. > > This is for example what happens in Morphic, and as a result I am > forced to create a Model class for a custom Morph, even if the > customization is minimal. This is a hurdle when you are in prototype > mode. Instead I would like to have the possibility to prototype faster > using blocks instead of creating a class. > > This is possible right now for unary methods when the framework does > not directly do a perform:, but instead it does: > > selector value: receiver. > > Ideally, we could have in the entire image only one place in which > perform: is called explicitly: in the Symbol>>value:. In this way, I > will be able to pass a block everywhere a unary method is now used. > This is something we do when we want to use Smalltalk for scripting > (Mondrian and Glamour do that) > > The same case goes for Symbol>>value:value: . These two methods would > already cover the large majority of performs, but I would argue for > adding all possibilities of evaluating blocks and of performing > messages. > > If you are asking what do Symbol have to do with blocks from a > conceptual point of view, I will answer that when the Symbol is used > as a selector, it does nothing else but point to a piece of behavior. > Given that a Block does a similar thing, you can as well treat them in > a polymorphic fashion. > > The only question that remains in my mind is: does a modification like > this has the possibility of harming? I am not aware of a case in which > it is harmful, but who knows. > > Cheers, > Doru > > > On 20 May 2009, at 15:27, StÃ©phane Ducasse wrote: > >> value from Object and value: from Symbol are different >> with value: on Symbol you can do >> >> self collect: #abs >> >> :) >> >> On May 20, 2009, at 2:48 PM, Gabriel Cotelli wrote: >> >>> +1 to the removal of value: from Symbol.... >>> >>> On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli(a)gmail.com> >>> wrote: >>>> Given that in Pharo we have Symbol>>value:, are there any reasons >>> not >>>> to have also >>>> >>>> Symbol>>value: anObject value: anotherObject >>>> ^ anObject perform: self with: anotherObject >>> >>> While Symbol>>#value: is at the border of being readable, >>> Symbol>>#value:value: is even worse. It is not immediately obvious >>> what it does. The order of receiver and arguments is hardcoded and >>> thus the construct cannot be applied in most cases without rewriting >>> the code. Fixed arguments cannot be given. >>> >>> Instead of adding new #value: variants, we should rather try to >>> remove >>> Object>>#value which is a real nightmare ;-) >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 21, 2009

Re: [Pharo-project] SGrid

by StÃ©phane Ducasse

what is SGrid? Porting from? Any effort in providing new cool widgets to pharo is really important. I can test but other than that my plate is full. Stef > Anyone willing to collaborate in porting and testing SGrid out there? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 21, 2009

Re: [Pharo-project] PlotMorph

by StÃ©phane Ducasse

Thanks carlos Now the question: - did you sign the license agreement? Please do. - do you know if there is a project for PlotMorph? Stef On May 21, 2009, at 6:09 AM, Carlos Crosetti wrote: > Fixed to run from Pharo. Attached, regards, Carlos<Plot- > Morph.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 21, 2009

Re: [Pharo-project] ThirtyTwoBitRegister methods removed

by StÃ©phane Ducasse

If you need them for glorp copy them from Squeak and publish a new package version working for Glorp in PharoInbox I will push it in pharo On May 21, 2009, at 3:07 AM, Mariano Martinez Peck wrote: > I searched in Monticello for the package System-Digital Signatures > and in the Pharo repository I only see two commits and even in the > first one, these two methods are not there. But, they are in Squeak. > So, know I guess where this commit should be? where I can search ? > > Thanks! > > Mariano > > On Mon, May 18, 2009 at 9:27 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > > wrote: > Hi folks. I noticed that this two methods were removed from > ThirtyTwoBitRegister: > > asByteArray > ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: > -8) with: (hi bitAnd: 16rFF) with: (hi bitShift: -8) > > > > reverseLoadFrom: aByteArray at: index > "Load my 32-bit value from the four bytes of the given > ByteArraystarting at the given index. Consider the first byte to > contain the mostsignificant bits of the word (i.e., use big-endian > byte ordering)." > > hi := ((aByteArray at: index + 3) bitShift: 8) + > ( aByteArray at: index + 2). > low := ((aByteArray at: index + 1) bitShift: 8) + > ( aByteArray at: index). > > > > I need them for Glorp. I looked but I didn't found a similar message > for them. I don't think adding them as an extension is a good > solution here since this seems to be very "internal". is there a > reason of the removing? If not, could them be added again? If there > are reason, which should be the best approach to fix this in mi case? > > I have no problem in commit them if you want. > > Thanks! > > Mariano > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 21, 2009

Re: [Pharo-project] Error when trying to create a package

by StÃ©phane Ducasse

> > I added that ability to Installer ages ago. Installer cache > install: 'Morphic'. Ok I was not aware of that. > > > Or you want it to search the cache without changing the script? > hmm. good idea. I'll make that work Yeap :) something like Installer install: 'Morphic' and a default to not use the cache to do a real reload Installer ignoreCache install: .... Stef

May 21, 2009

Re: [Pharo-project] Win32Setup - custom VM and app tutorial

by Janko MivÅ¡ek

Hi Torsten, I just tried it and I'd really like to thank for moving Smalltalk much closer to usually spoiled Windows user, who won't even touch anything without such installation as you provided. Big step forward in usability terms, really! Now just Pharo needs to be less scary when first opened by such user. Because now it is scary. It was even for me - after such easy and normal installation you end up with some blank screen with just those cryptic references open. Hmm, what to do now? So, there is at least some short text needed to encourage user to explore further, at least a reference to Squeak by example book. And how to open a Class browser ... Best regards Janko Torsten Bergmann pravi: > there is now a ready made setup for installing pharo on windows. > > http://gforge.inria.fr/frs/download.php/22307/setup_pharo_0.0.0.1.exe > > It is available in the Win32 Setup section on > http://gforge.inria.fr/frs/?group_id=1299 > > Far from perfect, but working. Use at your own risk! -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

May 21, 2009