May 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Support for stdout without OSProcess (issue 4065)
by Stefan Marr May 16, 2011

May 16, 2011

Hi: What needs to be done for issue 4065? http://code.google.com/p/pharo/issues/detail?id=4065 I would like to have an easy way to provide compatibility for the RoarVM primitive RVMOperations>print: which really just dumps a string to stdout. So, ideally, I don't want to many dependencies like OSProcess in SMark. What would need to be done for that? The issue is not to verbose. Is it a missing print primitive in the VM? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

4 8

[Pharo-project] LAst Phato core, Zn and proxy [WAS] Re: 1.3-Core
by Mariano Martinez Peck May 16, 2011

May 16, 2011

Hi. I didn't follow the long thread, but in latest PharoCore (when Zn is present) I cannot use monticello because I cannot get out. I am behind a proxy but with the previous network library it worked out of the box. Is this the same problem of Alexandre? is there an issue in the bugtracket? can we integrated? is there a workarround so that I can continue using my image? Thanks Mariano On Fri, May 13, 2011 at 3:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I updated Zinc-HTTP and Zinc-Tests from your server. > Running the tests gives me: 151 run, 151 passes, 0 expected failures, 0 > failures, 0 errors, 0 unexpected passes > > Really cool! > > Alexandre > > On 13 May 2011, at 09:39, Sven Van Caekenberghe wrote: > > > > > On 13 May 2011, at 15:24, Alexandre Bergel wrote: > > > >> I use a core 13197. Running Zinc tests gives me: > >> 146 run, 118 passes, 0 expected failures, 28 failures, 0 errors, 0 > unexpected passes > > > > For all tests to pass, you need the very latest version (160) where the > proxy is bypassed for localhost. > > Also, make sure no other ZnServers are running (they would block the 1701 > port needed by the tests). > > > > Sven > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

3 4

[Pharo-project] [update 1.3] #13202
by StÃ©phane Ducasse May 16, 2011

May 16, 2011

13202 ----- - Issue 4231: To make sure that we can deprecated RecentMessageSet. - Cleaning FlatBrowser

1 0

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations
by mkobetic＠gmail.com May 16, 2011

May 16, 2011

"Miguel CobÃ¡"<miguel.coba(a)gmail.com> wrote: > 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. These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here. The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SS…) Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)? Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-). My 2c, Martin

4 9

[Pharo-project] squeaksource is down :(
by Mariano Martinez Peck May 16, 2011

May 16, 2011

Thanks -- Mariano http://marianopeck.wordpress.com

2 1

[Pharo-project] [Hudson] update
by Marcus Denker May 16, 2011

May 16, 2011

-> 1.2 and 1.3 (both core and Full) are on the way to be green at the same time for the first time. -> We added some projects to the TaskForces: Ring: https://pharo-ic.lille.inria.fr/hudson/job/Ring/ A new Meta Model for code Fuel: https://pharo-ic.lille.inria.fr/hudson/job/Fuel/ Serializer Nautilus: https://pharo-ic.lille.inria.fr/hudson/job/Nautilus/ Browser Nile: https://pharo-ic.lille.inria.fr/hudson/job/Nile/ Streams, rewritten with Traits (used to be part of Full, parked here until we have manpower to look at it and push it...) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Amazon AWS S3 Monticello Mirror
by Marcus Denker May 16, 2011

May 16, 2011

On May 15, 2011, at 11:12 PM, StÃ©phane Ducasse wrote: > thanks this is an excellent initiative. > Marcus will love that. > Yes! We should get that setup... very nice! Whose Amazon Account do we use? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] XML maintainer??? Fwd: [Pharo-bugtracker] Issue 4232 in pharo: Failing Tests in Full: XML
by Mariano Martinez Peck May 16, 2011

May 16, 2011

So...we added XML to PharoDev. Where are the maintaners? Could you please check these issues? Thanks! mariano ---------- Forwarded message ---------- From: <pharo(a)googlecode.com> Date: Sun, May 15, 2011 at 8:50 PM Subject: [Pharo-bugtracker] Issue 4232 in pharo: Failing Tests in Full: XML To: pharo-bugtracker(a)lists.gforge.inria.fr Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3-DevImage New issue 4232 by marcus.d...(a)gmail.com: Failing Tests in Full: XML http://code.google.com/p/pharo/issues/detail?id=4232 XML.Tests.Parser.Nodes.XMLObservableListTest.testReplaceFromToWithStartingAt >>> 0.0 1 >>> XML.Tests.Parser.Nodes.XMLOrderedListTest.testReplaceFromToWithStartingAt >>> >> _______________________________________________ Pharo-bugtracker mailing list Pharo-bugtracker(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker -- Mariano http://marianopeck.wordpress.com

1 1

[Pharo-project] [TODO] Bug Tracker Status (429)
by Marcus Denker May 16, 2011

May 16, 2011

Hello! The weekly bug tracker status report. Open Issues: 429 http://code.google.com/p/pharo/issues/list For starters, looking at the ones tagged "1.3" is best: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 These should contain only things -> that are real show stoppers for a release -> We *really* *really* want them -> failing tests -> things that look good that only need to be integrated Another good starting point are issues tagged "easy": http://code.google.com/p/pharo/issues/list?can=2&q=difficulty=Easy -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations
by Sven Van Caekenberghe May 16, 2011

May 16, 2011

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

6 18