- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [COTDC] 62 - MIMEType

by laurent laffont

On Tue, May 10, 2011 at 8:31 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: MIMEType > I guess and represent the content type of a file. For a description of what is MIME, see http://en.wikipedia.org/wiki/Internet_media_type http://en.wikipedia.org/wiki/MIME Examples: MIMEType forFileNameReturnMimeTypesOrDefault: 'index.html'. MIMEType fromMIMEString: 'application/zip'. Laurent. > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

May 12, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 61 - InternetConfiguration

by laurent laffont

On Thu, May 12, 2011 at 4:17 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 12, 2011, at 3:41 PM, laurent laffont wrote: > > > On Mon, May 9, 2011 at 8:34 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > > Today: InternetConfiguration > > > > I read several parameters related to the OS network preferences, through > the InternetConfigPlugin VM module. > > > > For example, to get the default path where downloaded files should be > placed: > > > > InternetConfiguration getDownloadPath > > > > > > (That said, it's not used in the image). > > > > It is... it's in the startup list and setting the Proxy at SCG since years > automatically. > (it's only working on the Mac, though) > Thanks for the info, added. Laurent. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

May 12, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by StÃ©phane Ducasse

On May 12, 2011, at 4:31 PM, Rob Withers wrote: > Stef, > > The Cryptography project, which has Cryptography, CryptographyPlugins, LayeredProtocol and SSL packages are all tagged with pharo. When I look at the pharo tag, none of these show up. Do they need to be releases? By tag I do not know :) > How can I use the pharo tag from inside of Pharo, with the Monticello Browser? > > Rob > > -----Original Message----- From: StÃ©phane Ducasse > Sent: Thursday, May 12, 2011 10:10 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations > > Or you keep > Cryptology and publish a pharo tag. > > Stef > > On May 12, 2011, at 3:52 PM, Rob Withers wrote: > >> Try this, after loading the Crypto packages. I haven't tried it myself, yet, as I only got on this list and loaded Pharo a few days ago, but I will probably dig into it over the weekend. I did load Crypto, though. >> >> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz >> >> Is there a Pharo repository I could drop ported code into? >> >> Regards, >> Rob >> >> >> >> >> >> -----Original Message----- From: Sven Van Caekenberghe >> Sent: Tuesday, May 10, 2011 1:42 PM >> To: Pharo Project >> Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations >> >> SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations >> >> >> HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality. >> >> Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream. >> >> Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution. >> >> >> First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms. >> >> The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited. >> >> Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient. >> >> Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well. >> >> Next the existing issues with certificates need to be resolved, on all 3 platforms. >> >> Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed. >> >> The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's. >> >> Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field. >> >> Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community. >> >> >> The bounty should be split in different parts. >> >> The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed. >> >> Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered. >> >> The goal should be to include the plugin in VM's by default. >> >> With a proper solution to the plugin issues, SSL server functionality should be no problem. >> >> >> I offer to take on part one and help manage the coordination of this project. >> >> So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ? >> >> Are there others who wish to raise the bounty ? >> >> We will need a couple of good beta testers who understand this field as well. >> >> >> Sven >> >> >> > > >

May 12, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by StÃ©phane Ducasse

Igor could you open a ticket that we do not forget. Stef > It seems like that with this change i opened a can of worms. > There are some tricky logic somewhere ,which uninstalls methods from > classes and then adds them back. > So, i added #dropSourcePointer at uninstalling .. then compilation > becomes too slow (because embedding source code using #becomeForward: > ). Then i changed #dropSourcePointer to actually erase the trailer > without using #become .. > but then some methods lost their source. > >> Decompiled code for old methods which were moved as part of a truncation, >> where the new versions have the exact same, and correct source doesn't sound >> like the end of the world to me. The method itself did not actually change. >> >> Cheers, >> Henry >> > > > -- > Best regards, > Igor Stasenko AKA sig. >

May 12, 2011

[Pharo-project] [update 1.3] #13196

by StÃ©phane Ducasse

13196 ----- - Issue 4130: Zinc should be added to core. Thanks sven van caekenberghe. Stef

May 12, 2011

Re: [Pharo-project] [MethodTrailer] #getSourceCodeBySelector: and #getSourceCodeByIdentifier: are not implemented

by Igor Stasenko

For #getSourceCodeByIdentifier: the idea was to introduce a source manager, which could manage source code by using some arbitrary IDs. Then you can store source code in database or on web.. depending how source manager is implemented. And for getSourceCodeBySelector: i did a trick to actually answer the source modified by comment (if method is originally comes from trait) so for example when method belongs to trait, then you will see something like: "This method implemented in TMyTrait" fooo ^ self then you will think twice before modifying such methods, because if you do that, you will replace it in class where you doing, but maybe you should do it in trait. But this change were not integrated. On 12 May 2011 16:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > I vote for removing any dead code. Less code, less bugs. Less code, easier to understand. > > On May 12, 2011, at 3:45 PM, Mariano Martinez Peck wrote: > >> If we see CompiledMethodTrailer >> sourceCode >> Â Â "Answer the source code of compiled method. >> Â Â Note: it does not attempts to read from source files using sourcePointer, >> Â Â nor reconstruct the source code using temp names" >> >> Â Â (kind == #EmbeddedSourceQCompress or: [ kind == #EmbeddedSourceZip ]) ifTrue: [ >> Â Â Â Â ^ data ]. >> >> Â Â kind == #SourceBySelector ifTrue: [ >> Â Â Â Â ^ method methodClass getSourceCodeBySelector: method selector ]. >> >> Â Â kind == #SourceByStringIdentifier ifTrue: [ >> Â Â Â Â ^ method methodClass getSourceCodeByIdentifier: data ]. >> >> Â Â ^ nil >> >> >> But neither #getSourceCodeBySelector: nor #getSourceCodeByIdentifier: Â are implemented. In fact, it is easy to modify their test and make them red. Change #testSourceBySelectorEncoding or #testSourceByIdentifierEncoding and add a send to #sourceCode. Example: >> >> testSourceBySelectorEncoding >> >> Â Â | trailer | >> >> Â Â trailer := CompiledMethodTrailer new. >> >> Â Â trailer setSourceBySelector. >> >> Â Â self assert: (trailer kind == #SourceBySelector ). >> Â Â self assert: (trailer size = 1). >> Â Â trailer sourceCode. >> >> >> >> So...I don't know why they are not implemented, but if this was work "unfinished", we should at least make that clear and not to appear that it is supported but at the end it is not. So, if that's the case, I suggest to put nice comments explaining that and in addition implement: >> >> Behavior >> getSourceCodeBySelector: >> ^ self notYetImplemented >> >> >> Behavior >> getSourceCodeByIdentifier: >> ^ self notYetImplemented >> >> >> What do you think ? >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

Re: [Pharo-project] SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations

by Sven Van Caekenberghe

On 12 May 2011, at 17:58, Rob Withers wrote: > Sure. I cannot recall if I offered a stream interface or not. > I could add one and we could treat this and the SqueakSSL stream as provider impl to a wrapper stream. The code that I am working on has a good [Secure]SocketStream implementation, it depends on a Socket like object, and on an SSLSession, which currently is the plugin. I imagine that it could also be your code. > I'll comment more as I dig into it. I think I will fork a PharoSSL project, since I know of at least one change in there. If I understood correctly, you need all of Cryptography, right ? So would it not make more sense to (if necessary), start or add a Cryptography-Pharo ? I mean, your code is much more than SSL. Sven

May 12, 2011

Re: [Pharo-project] [squeak-dev] [ANN] VB-Regex patch available

by Miguel CobÃ¡

Lukas Renggli maintained the VB-Regex on Pharo. He tried IIRC to get Vassily to accept some patches but it appears that he didn't get any response from him. Lukas will be interested in these patches for sure. Regards El jue, 12-05-2011 a las 16:28 +0200, Nicolas Cellier escribiÃ³: > Reinout Heek recently published a patch in cincom store for some Regex > pending bugs after a recent mail on vwnc list. > I ported this 3-methods patch on Squeak based on latest > http://www.squeaksource.com/Regex.htm > I have no commit right, so I posted two copies: > > http://source.squeak.org/inbox/VB-Regex-nice.18.mcz > http://www.squeaksource.com/PharoInbox/VB-Regex-nice.18.mcz > > Note that core Pharo version of Regex is some versions ahead and the > patch requires further porting. > > Nicolas > > > ------------------------------------------------------------------------- > Port fixes from Reinout Heek from VW.Regex11 > > Regex11(1.3.1-soops1) - introduces fix > Regex11(1.3.3) - merge above with 1.3.2 > > Blessing comment: > > Fixed RxmBranch to do greedy matching instead of first match passes. > This entailed adding a collection copy to #currentState, so I > expect this to slow down Regex11 a bit (not measured yet). > > This fixes a bug found a Soops: > '.*(ABCD|BC)' asRegex matches: 'fooABCD' > and Mantis bug 5391: > '15' matchesRegex: '[1-9]|1[0-9]' > > See http://bugs.squeak.org/view.php?id=5391 > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 12, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by Miguel CobÃ¡

El jue, 12-05-2011 a las 16:53 +0200, Sven Van Caekenberghe escribiÃ³: > Rob, > > On 12 May 2011, at 16:38, Rob Withers wrote: > > > It is a complete implementation with the bare minimum of supported algorithms, based on the spec. It is 100% in Smalltalk. It worked last time I tested in, several years ago. I will be able to tell you more this weekend. Others have been adding fixes/small features since, but not a lot - the base is pretty solid. I painstakingly followed the RFC for SSL - I think I read it over 20 times! The only issue would be algorithm support. I never benchmarked it, but seeing the difference in performance between Smlltalk crypto code like 3DES and plugin code, there is a SIGNIFICANT improvement (10x?). I do not know the state of Profiling under Pharo. If someone could help set me up, then I will profile it this weekend. I imagine both performance and certification were the reasons for SqueakSSL. > > > > There is also an SSH implementation I wrote that does dynamic window resizing on net latency. > > It would be *very cool* if that code base could be ported to Pharo. > It is really quite impressive that you did all this from the spec. > > I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc.. > > Does that sound like a good idea ? But the performance is an issue. And I think that there was a discussion several years ago that lead to choice a plugin instead of the all-smalltalk code (independently of the queality of the smalltalk code). Also a point was made about the maintainability of the smalltalk code with respect to a library of the underlying OS, with respect to CERT issues and 0-day exploits. given the few resources in the community for simpler (relative to crypto) projects like *completion, RB and so, I think is a wise decision to use the proved, tested and maintained OS libraries through a plugin part of the standard VM. Of course, the smalltalk implementation can be used as a fallback for platforms where a plugin isn't available. Cheers > > Sven > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 12, 2011

Re: [Pharo-project] SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations

by Rob Withers

Sure. I cannot recall if I offered a stream interface or not. I could add one and we could treat this and the SqueakSSL stream as provider impl to a wrapper stream. I'll comment more as I dig into it. I think I will fork a PharoSSL project, since I know of at least one change in there. Rob -----Original Message----- From: Sven Van Caekenberghe Sent: Thursday, May 12, 2011 10:53 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations Rob, On 12 May 2011, at 16:38, Rob Withers wrote: > It is a complete implementation with the bare minimum of supported > algorithms, based on the spec. It is 100% in Smalltalk. It worked last > time I tested in, several years ago. I will be able to tell you more this > weekend. Others have been adding fixes/small features since, but not a > lot - the base is pretty solid. I painstakingly followed the RFC for > SSL - I think I read it over 20 times! The only issue would be algorithm > support. I never benchmarked it, but seeing the difference in performance > between Smlltalk crypto code like 3DES and plugin code, there is a > SIGNIFICANT improvement (10x?). I do not know the state of Profiling > under Pharo. If someone could help set me up, then I will profile it this > weekend. I imagine both performance and certification were the reasons > for SqueakSSL. > > There is also an SSH implementation I wrote that does dynamic window > resizing on net latency. It would be *very cool* if that code base could be ported to Pharo. It is really quite impressive that you did all this from the spec. I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc.. Does that sound like a good idea ? Sven

May 12, 2011