- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Need help with 1.3 Full Image

by StÃ©phane Ducasse

lukas another important point. Imagine that people would have tested their software during the RC phase then we would have spotted and fixed theses bugs (I do not take into account OB bug because we cannot maintain it). So at the end, if people do not use and tests then there is less chance to spot bugs and what can we do. To me this is like that and this is not a big issues. Now even with two full time engineers it would not change that much but we would have the same problem. Too many different scenario to explore. Now another really important point: we are not just maintaining a smalltalk but building an infrastructure for the next 10 years and we have limited amount of time (you know our job - this week I was 3 days in hiring meetings - important and now I accepted to be scientific head of our lab). So everybody is busy and working and I think that given these constraints we are doing a good job given that Pharo is not our only focus. We will soon apply systematically lint rules to pharo and will increase again the quality. Now if you want to join to build the next generation Smalltalk just join and have fun with us. I felt that you were pissed off but you should not get frustrated. We have 5 years to really do something really cool and we are doing. OPAL is moving again, the new package is going forward, igor is working on a new canvas to support zoomable interface, native boost, we will have a bootstrappable core, new network, files, new ClassBuilder, first class slots,..... Stef On May 13, 2011, at 6:41 PM, Lukas Renggli wrote: > Hi Stef, > >> uh? what are these bugs? > > From the top of my head these are all bugs that appeared in the past > weeks and that were not present in Pharo 1.1: > > - temps and method selector changes that disappear and that are not > logged in the changes file > - text formatting that vanishes from larger texts > - mouse selection that is broken > - various OB bugs, such as broken smart chars, scroll bar, tests, text > search, ... > >> I'm really surprised. I'm also surprised that you say that when you did not >> even tried to port your tools to 1.2 during the release candidate phase and that people >> tried and failed and you started to port your tool when 1.2 was released. >> You were undermining our process sadly. > > I was moving to a different place, starting with a new job, and > learning new things. > > I don't have the energy and interest to constantly run after the > latest releases. I want to use something stable to work with in the > little spare time I have, and not be constantly disturbed by new > problems that show up because something subtle changed. For me Pharo > 1.2.x will be the last version until something really compelling shows > up ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

May 14, 2011

Re: [Pharo-project] RMLL anyone?

by StÃ©phane Ducasse

I will see. So far they look quite unprofessional with me. I got no reply from my seaside talk and the pharo talk was rejected. Stef On May 14, 2011, at 10:12 AM, Hilaire Fernandes wrote: > I will be there at Strasbourg from 9 to 14 of Jully - http://www.rmll.info > > Any Pharoer is joining? > > Hilaire > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

May 14, 2011

[Pharo-project] RMLL anyone?

by Hilaire Fernandes

I will be there at Strasbourg from 9 to 14 of Jully - http://www.rmll.info Any Pharoer is joining? Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

May 14, 2011

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

by StÃ©phane Ducasse

>> > > I accelerated raisedTo:modulo: a bit with a primitive > (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins. Stef

May 14, 2011

[Pharo-project] redundancy

by StÃ©phane Ducasse

Yes. So how do we do that? Dale can we use the ssgemstone you host? Stef >> > The problem is that the network operator is down... > > see http://code.google.com/p/pharo/issues/detail?id=4218 > > We should really t hink hard about redundancy... >

May 14, 2011

Re: [Pharo-project] We are still small, don't worry

by Luc Fabresse

2011/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com> > Taking the latest PharoCore 1.3 and doing "ScriptLoader new > cleanUpForProduction" (mostly cleanUps and tests removal ) > > Gives me a 6.9 MB image. So we are quite good. really good! Tanks Mariano and others for the effort! #Luc > > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

May 14, 2011

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

by Nicolas Cellier

2011/5/14 <mkobetic(a)gmail.com>: > "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…) > I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas > 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 > > >

May 13, 2011

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

by mkobetic＠gmail.com

"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

May 13, 2011

Re: [Pharo-project] Help "migrating" from classic streams to XStreams

by mkobetic＠gmail.com

"Mariano Martinez Peck"<marianopeck(a)gmail.com> wrote: > Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary > serializer similar to Parcels. More info in > http://rmod.lille.inria.fr/web/pier/software/Fuel > > For the moment, we are using the "classic" streams we want to give it a try > to XStreams. My knowledge on streams is very little, so if someone can give > me a hint I would really appreciate it. > What I want to do right now is an adaptor of XStreams to classic stream. I > mean, I want to create custom subclasses of XTFileWriteStream and > XTFileReadStream that implements the same API from classic streams that we > use in Fuel. And the implementations of such methods will do just a "self > something" where something is the way of doing that in XStreams. I'd also recommend generic wrapper for any kind of Xtream rather than subclassing specific terminal. In VW the usual way to create the classic streams is via #readStream or #writeStream, so I'd add something like: XTReadStream>>readStream ^XTClassicReadStream on: self XTWriteStream>>writeStream ^XTClassicWriteStream on: self The "classic" guys would then implement the classic API by invoking Xtreams API on their source/destination. You can even subclass those from the classic ReadStream and WriteStream to possibly inherit some behavior and only implement some core part of the protocol. > So, the following is the protocol we use in Fuel for streams, and what I > would love to know is the associated way to do it it XStreams. The left is > classic streams, and after the "->" it is XStreams: > > *Reading:* > > nextNumber: -> ?? > nextPutAll: -> write: > nextStringPut: -> ?? > nextPut: -> put: > nextNumber:put: -> ?? > nextWordPut: -> ?? > > *Writing: > * > nextNumber: -> ?? > next: -> read: It's not as simple, there can be subtle differences. For example in VW it should be something like: next: anInteger ^[ source read: anInteger ] on: Incomplete do: [ :incomplete | IncompleteNextCountError new parameter: incomplete count; raiseRequest ] > nextString -> ?? > next -> get Again, in VW it would be more like: get ^[ source get ] on: Incomplete do: [ :incomplete | EndOfStreamNotification raiseRequest ] > nextWord -> ?? For the specialized element types (Number, String) you can pretty much copy the classic implementations (or even inherit them). Alternatively they seem to fall into a category that we call "interpreting" in Xtreams. What we have is primarily focused on interpreting bytes as various C-types (short, long, float, double,....) for which we have convenient primitives in VW, but the concept can certainly be extended further (the interpretation definitions are pluggable). Unfortunately this part wasn't ported yet from VW. For quick overview you can peek at the end of http://code.google.com/p/xtreams/wiki/Transforms. There's also general marshaling stream available on VW side (built on top of the interpreting streams) which might be helpful example of how one can approach this type of problem with Xtreams. HTH, Martin

May 13, 2011

[Pharo-project] We are still small, don't worry

by Mariano Martinez Peck

Taking the latest PharoCore 1.3 and doing "ScriptLoader new cleanUpForProduction" (mostly cleanUps and tests removal ) Gives me a 6.9 MB image. So we are quite good. Cheers -- Mariano http://marianopeck.wordpress.com

May 13, 2011