October 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Cannot browse senders of #binary

by nicolas cellier

Browse senders of #binary and... MessageSet >> #methodDisplayStringForClass:selector: -> ByteString doesNotUnderstand: #packageName This change seems recent.

Oct. 16, 2008

[Pharo-project] copy dependent packages

by StÃ©phane Ducasse

Hi guys did one of you implement copy which pay attention to copy also the dependent packages to a given repository? Because it would be really cool to have that. Stef

Oct. 16, 2008

[Pharo-project] About etoy removal

by StÃ©phane Ducasse

hi all After spending a couple of hours redoing I imagine the same process as Gary and reading all the code I can tell you that people wanting Etoy to load back in any squeak versions do not know what they were talking about. seriously! I'm amazed by the amount of abstractions that could have been put elsewhere. Now if we try to learn from that here is my take on it: I think that what was missing is a kind of layering system so that etoy developers could enhance Morph (since I imagine that they wanted that any objects in the system could be scriptable, react as a card.....) but layer it and remove cleanly. May be a kind of classboxes system is what they should have implemented so that when you were in etoy you could get all the stuff but when when you are out of the etoy project you would get a nice little morphic. Stef

Oct. 16, 2008

[Pharo-project] About a better way to curving out etoy

by StÃ©phane Ducasse

hi guys I would like to get some support from the tools to help us curiving out etoys. Here is the scenario: when I see a method I would like to see a color or symbol which tell me how many sender kinds were calling this method either statically or dynamically. I would like to put etoy classes in red and see the colors propagating in the system. So we could get a kind of coloring schema. We could do the same with letters then we could have some single colored methods or mix Alex/Damien do you want to help because this could be fun? Then when i see how I work I always do a kind of yoyo between senders and implementers it would be really interesting to log the senders and implementers so that we could trace back the sequence and understand also how the remove happen and the frequency of the removal. Stef

Oct. 16, 2008

Re: [Pharo-project] Removing default fonts

by StÃ©phane Ducasse

sounds good to me. Stef On Oct 15, 2008, at 10:31 PM, Adrian Lienhard wrote: > In another thread (Pharo image size: 10.9MB) I proposed to remove > all but one font since the ones in the image (especially the TT > fonts) are not really useful but consume memory. Hilaire suggested > to keep Accujen, which to my eyes looks better than the default > Accuny font (not perfect, but better..). > So I suggest to change the default to Accujen, keep the current > default Accuny, and remove all other fonts. The script below does > this so you can try it out if you are interested. It frees roughly > 2k, but eventually with more cleanup it will have a bigger impact > because the TT font instances are still referenced from other places > in the system. > > Adrian > > > Preferences setDefaultFonts: #( > (setSystemFontTo: 'Accujen' 12) > (setListFontTo: 'Accujen' 12) > (setMenuFontTo: 'Accujen' 12) > (setFlapsFontTo: 'Accujen' 14) > (setEToysFontTo: 'Accujen' 12) > (setPaintBoxButtonFontTo: 'Accujen' 12) > (setWindowTitleFontTo: 'Accujen' 12) > (setBalloonHelpFontTo: 'Accujen' 12) > (setCodeFontTo: 'Accujen' 12) > (setButtonFontTo: 'Accujen' 12)). > > Preferences setWindowTitleFontTo: (Preferences windowTitleFont > emphasized: 1). > Preferences setFlapsFontTo: Preferences windowTitleFont. > > TextConstants associations do: [ :association | > ((association value isKindOf: TextStyle) > and: [ association key ~= #Accuny ] > and: [ association key ~= #Accujen ] > and: [ (TextStyle defaultFamilyNames includes: association key) > not ]) > ifTrue: [ TextConstants removeKey: association key ]]. > #(#DefaultFixedTextStyle #DefaultMultiStyle) do: [ :key | > TextConstants at: key put: (TextConstants at: #DefaultTextStyle ) ]. > > PartsBin clearThumbnailCache. > Smalltalk garbageCollect > > > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2008

[Pharo-project] About nextPut:

by StÃ©phane Ducasse

Hi damien I was looking at the following code Sequenceable>>flatCollect: aBlock "Evaluate aBlock for each of the receiver's elements and answer the list of all resulting values flatten one level. Assumes that aBlock returns some kind of collection for each element. Equivalent to the lisp's mapcan" "original written by a. Kuhn and released under MIT" | stream | self isEmpty ifTrue: [^self copy ]. stream := (self species new: self size) writeStream. self do: [ :each | stream nextPutAll: (aBlock value: each) ]. ^stream contents and if we send the message to a set we get a problem because WriteStream>>nextPut: anObject "Primitive. Insert the argument at the next position in the Stream represented by the receiver. Fail if the collection of this stream is not an Array or a String. Fail if the stream is positioned at its end, or if the position is out of bounds in the collection. Fail if the argument is not of the right type for the collection. Optional. See Object documentation whatIsAPrimitive." <primitive: 66> ((collection class == ByteString) and: [ anObject isCharacter and:[anObject isOctetCharacter not]]) ifTrue: [ collection := (WideString from: collection). ^self nextPut: anObject. ]. position >= writeLimit ifTrue: [^ self pastEndPut: anObject] ifFalse: [position := position + 1. ^collection at: position put: anObject] so the solution is to specialize flatCollect: on Set flatCollect: aBlock "Evaluate aBlock for each of the receiver's elements and answer the union of all resulting values. Assumes that aBlock returns some kind of collection for each element." | set | self isEmpty ifTrue: [^self copy]. set := Set new. self do: [ :each | set addAll: (aBlock value: each) ]. ^set Now I was wondering if there is way to avoid that. Stef

Oct. 16, 2008

Re: [Pharo-project] [ANN] new 10095 prebuild image

by Marcus Denker

On 16.10.2008, at 13:00, Torsten Bergmann wrote: > Marcus wrote: >> one-click will come soon, too. > > Will this be based on the newest VM sources so we can close issue 231? > (I typically use the full screen mode to forget about the boring OS ;) > Yes, I will try to update the windows vm, too. In addtion, we should fix the Logo. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 16, 2008

Re: [Pharo-project] One click feature list request/question

by StÃ©phane Ducasse

Yes this is important! Stef On Oct 16, 2008, at 9:55 AM, Lukas Renggli wrote: >> But then, the new FFI of Eliot seems to be far, far better then the >> old >> one. >> It would be nice to have that instead. E.g, it supports callbacks >> nicely >> and >> is much faster. > > Go Eliot, go! It is crucial that Smalltalk gets better bindings with > the outside world. It should be easy (as with Python or Ruby) to > integrate some external C library. > > I hope the new FFI doesn't need to hack the Smalltalk language and > compiler. > > 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 >

Oct. 16, 2008

[Pharo-project] [updates] 10096

by Marcus Denker

update10096 ----------- Issue 247: remove #hashMappedBy: Issue 243: SMTPClient fix for authentication and support for EHLO (Mantis #6768) Issue 233: fix for BreakPoint Issue 229: remove preference Panel -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 16, 2008

[Pharo-project] One click feature list request/question

by Torsten Bergmann

Alexandre wrote >JavaConnect is pretty easy to use and works quite well. >But there is no port to Squeak as far as I am aware of. As I said in the "future" - if pharo grows and is used in commercial applications the pressure may be high enough. Since I work with both languages I might have a look sooner or later myself. As always this mostly depends on time. Or it may become the next Google Summer of code project for a student. According to the comments Joachim made on my blog [1] JNIPort may be easier to port than JavaConnect. It was already ported from Dolphin to VW, supports callbacks and does not require namespaces. On the other hand namespaces are planned for Pharo too. So we will see... At least we need a good FFI since Java is not the only interesting technology out there to integrate. Keep on talking small Torsten [1] http://astares.blogspot.com/2008/04/javaconnect-java-assmalltalkvalue.html?… -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Oct. 16, 2008