- Pharo-dev - lists.pharo.org

Re: [Pharo-project] OBMorphicIcons (was Re: this style looks cool)
by Rob Rothwell Aug. 31, 2010

Aug. 31, 2010

Thanks both of you for pointing me in the right direction. I was able to get something similar to what is in OBMorphicIcons>>breakpoint by doing this: methodContents := WriteStream on: ''. (OBMorphicIcons iconNamed: #breakpoint) storeOn: methodContents. methodContents inspect. But the contents are different, and if you substitute them for the contents of breakpoint, the picture looks different too... Thank you, Rob > *contents := (StandardFileStream fileNamed: 'loop_icon.jpg') contents. > encondedContents := (Base64MimeConverter mimeEncode: contents readStream) > .* > > That basically gives you the string you have to embed in a method... > > Cheers, > Guille > > On Mon, Aug 30, 2010 at 9:42 AM, Alexandre Bergel <alexandre(a)bergel.eu > >wrote: > > > > > > > This looks useful; how do you turn an image into a method, though? > > > > Hi! > > > > Have a look at the class side of MenuIcons. There are a bunch of > > import/export methods. > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >

1 0

Re: [Pharo-project] Pharo-project Digest, Vol 28, Issue 282
by James Ladd Aug. 30, 2010

Aug. 30, 2010

Hi Eliot, I cant use those thinks because im not in Smalltalk at the time, im in Java on the JVM. (Did someone say 'challenge') I thought about the store question in the shower this morning and I think it means take the top of the stack but dont pop it. Please let me know if Im wrong? Rgs, James. > Hi James, > > perhaps you could use the implementations of > ContextPart pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: > storeIntoRemoteTemp:inVectorAt: > (& Interpreter pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: if > you have them to hand) as the spec and check the documentation. The intent > is that k..k is the index of the temp containing the remote vector and j..j > is the index in the remote temp vector. > > cheers > Eliot >

2 1

[Pharo-project] Squeaksource default license (was Re: WebClient-Core port to Pharo 1.1 final)
by DeNigris Sean Aug. 30, 2010

Aug. 30, 2010

<quote author="Torsten Bergmann"> Maybe the license should be a required field in Squeaksource for any new project. </quote> Yes! /And/ *default to MIT.* Even though in this case Andreas chose other-than MIT on purpose, how many projects are not MIT simply because the default is a choice other than "the one most valuable to the community." Let's use this opportunity to improve for the future :) Sean

1 0

[Pharo-project] [update 1.2] #12120
by StÃ©phane Ducasse Aug. 30, 2010

Aug. 30, 2010

12120 ----- - Fix for post enh of methodReference (remove timeStamp:. and related). Sorry for the potential mess. Stef

1 0

[Pharo-project] OBMorphicIcons (was Re: this style looks cool)
by Rob Rothwell Aug. 30, 2010

Aug. 30, 2010

> Message: 4 > Date: Mon, 30 Aug 2010 03:41:45 +0200 > From: Tudor Girba <tudor.girba(a)gmail.com> > Subject: Re: [Pharo-project] this style looks cool > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: <6950297A-3FF9-46B5-9AC5-CAA382233986(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hi Bill, > > As I said, all you have to do is to override #browserIcon on the class > side of your class to return a symbol that corresponds to a method in > OBMorphicIcons. Please look at the implementors of #browserIcon. > > For example: > > Announcement class>>browserIcon > ^ #announcement > > OBMorphicIcons>>announcement > ^ ((ColorForm > extent: 12@12 > depth: 8 > fromArray: ... > > > Cheers, > Doru > This looks useful; how do you turn an image into a method, though? Thank you, Rob

3 2

[Pharo-project] WebClient-Core port to Pharo 1.1 final
by Torsten Bergmann Aug. 30, 2010

Aug. 30, 2010

Before some of us are continue to lament or are too quick in decisions like removing/forking/reimplementing the web lib or judging on all this I think it would be wise to wait for a response from Andreas. First: his response was directly to Sven (with Pharo in CC) and please reread what he wrote: >which are not (or not yet) under MIT. Which means there is a chance that the code will be under MIT. But as he wrote: >that I specifically didn't set a license on WebClient to prevent >such forks without any prior discussion It is fairly reasonable to discuss it first since all our time is limited and the more forks we have the more time may be wasted. A fork would only be necessary if Squeak and Pharo differ too much in the underlying base. Which again leads to the question if it would be possible to reshape both systems onto a common clean kernel ... but thats another story. I think that even a fork of a package would be no problem (you can hardly prevent it when you set something real open source) but there should be a way that contributions/fixes can be folded back into the original (external) code stream. >your repository incorrectly claims that the version of WebClient >in it is LGPLv2. Yes, Sven uploaded a "WebClient-Core-Sven....72.mcz" to squeaksource/ADayAtTheBeach and this repository is LGPLv2. Andreas was just surprised that someone relicensed his code even before he has put a license tag onto the original package. Same for the inclusion into the MIT licensed Pharo core image. On the other hand he published "ConfigurationOfWebClient-ar.1.mcz" into the MIT licensed squeaksource/MetacelloRepository instead of keeping the Configuration into the unlicensed package repository. So it looks like he wanted to do an MIT release ... However: Andreas has to put a license tag onto his code so we can finally stop this whole side discussion and continue to move forward >nobody in Pharo even tries to find out what the license status >for WebClient is. Yes ... looks like there was/is a missing/incomplete process in license checking >In short, my position is that we need more shared libraries, not >more forks +1 >I think WebClient should be an external package External <-> Internal is just a question of a modularized image and loading/unloading. In case of Andreas deciding for MIT and a code integration into the base images (Squeak, Pharo, ...) the community has one leading place for the code (the external package). Similar to what I do for HelpSystem. So Managing the code external is OK since this would allow all us all to load it into own custom images or merge changes into own custom adoptions (if they are necessary). In case Andreas decides for non-MIT there is no option - the community has to find a more open alternative if it wants to include it in Pharo or even port it to other Smalltalk systems (for instance to reuse the code in conjunction with Seaside on VW/VAST/...) My 2cent Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 €/mtl.!* http://portal.gmx.net/de/go/dsl

3 3

[Pharo-project] Magnitude should be reimplemented as a Trait
by jaayer Aug. 30, 2010

Aug. 30, 2010

I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. Additionally, I discovered that this message: isMetacelloConfig ^ false needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).

3 6

[Pharo-project] Information about ESUG 2010 conference
by Noury Bouraqadi Aug. 30, 2010

Aug. 30, 2010

Dear Smalltalkers, I'd like to remind you that all information about the ESUG conference is on-line as usual http://www.esug.org/Conferences/2010 you'll there many info including (but not limited to:) -The conference schedule: http://www.esug.org/wiki/pier/Conferences/2010/SchedulePDF?view=PRDownloadV… -Venue : http://www.esug.org/wiki/pier/Conferences/2010/Venue -A list of Hotels: http://www.esug.org/wiki/pier/Conferences/2010/Accomodation Last, a statistic: So far we have 133 registered people! Definitely the ESUG conference is the place to be to meet the community. For any question, please feel free to contact the esug board (board(a)esug.org) See you in Barcelona, Noury Esug treasurer

1 0

Aug. 30, 2010

hi guys after get burned during some years about the license of Squeak. What do you think to force people to put a license on projects on squeaksource? I have the impression that it would avoid bad situation in the future. Even if I could live with it like it is too. This is just that we just wait to get bitten... Stef

3 3

[Pharo-project] Where does an HTTP Client fit in ?
by Sven Van Caekenberghe Aug. 30, 2010

Aug. 30, 2010

Hi, Many valid things have been said from both sides regarding WebClient. As far as I understand it, there are 2 possible 'places' where code can reside: inside Pharo(Core) or outside. The inside code does not have to be compatible with other Squeak/Smalltalks (apart from maybe ANSI and other standards, I am not qualified here). The outside code can choose its compatibility target. Seaside goes very far here, but it hurts to think about the amount of effort that is being put in to achieve this (if it wasn't for the proof of its existence and portability, I would not believe this was even possible) (*) Some other packages might target just one Smalltalk. We cannot demand this from any other, even if it would be a good idea. My question is, where does a (future) HTTP Client fit in ? Both places are possible, one requiring more effort than the other. If I look at what is inside PharoCore, there is an important dependency on HTTP client access at least (Monticello, Updating, Gofer, ...). From that standpoint such a client should be 'inside'. Furthermore, many people have indicated that a good HTTP client (and/or server) is (are) very important today. Any Smalltalk looks silly without a proper HTTP implementation. Even though an 'outside' client (based on Grease for example) would be doable and a good idea, the 'inside' route feels more natural. BTW, In Java both exist (it is in the standard J2SE libs, and there are many clients, like http://hc.apache.org/ ). What do others think ? Sven (*) I respect this very much, it is a remarkable achievement.

1 0