- Pharo-dev - lists.pharo.org

Re: [Pharo-project] legal counsel for pharo?

by merlyn＠stonehenge.com

>>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: StÃ©phane> what is the position of squeak regarding the inclusion of qwak StÃ©phane> code in squeak? GPL code is incompatible with Squeak core, because it taints the entire distribution. (LGPL code *might* be permitted, but nobody has asked the question firmly enough yet. We'll have to consult counsel at that point.) Since OpenQwak is GPLv2, code from that distro is not allowed. However, some of the upstream components are released under a compatible license, and could be included if offered. It would *not* be possible to take the downstream patches from OpenQwak though, as once again, that would taint the distro. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

May 12, 2011

Re: [Pharo-project] About CompiledMethod category returning nil sometimes

by Mariano Martinez Peck

On Thu, May 12, 2011 at 3:53 PM, Markus Fritsche < fritsche.markus(a)googlemail.com> wrote: > 2011/5/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Stef. From what I can see, the category can be nil only when > > CompiledMethods are created for DoIts but not for regular > CompiledMethods. > > Even those which are under 'as yet unclassified' answer that and not > nil. > > I think there are some .mcz-s flying around that cause a nil category > on load - is that unrelated? > > I have no idea. In my experiments, as I wrote, all CM with nil were with selector DoIt or DoItIn: Maybe in another image there are .mcz as you said which have those CM with nil also... -- Mariano http://marianopeck.wordpress.com

May 12, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Henrik Sperre Johansen

On 10.05.2011 16:22, Igor Stasenko wrote: > On 10 May 2011 13:33, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 10.05.2011 12:44, Igor Stasenko wrote: >>> On 10 May 2011 11:27, Mariano Martinez Peck<marianopeck(a)gmail.com> wrote: >>>> On Tue, May 10, 2011 at 10:59 AM, Igor Stasenko<siguctua(a)gmail.com> >>>> wrote: >>>>> On 10 May 2011 09:48, Mariano Martinez Peck<marianopeck(a)gmail.com> >>>>> wrote: >>>>>> On Tue, May 10, 2011 at 9:41 AM, Marcus Denker<marcus.denker(a)inria.fr> >>>>>> wrote: >>>>>>> On May 10, 2011, at 9:32 AM, Mariano Martinez Peck wrote: >>>>>>> >>>>>>>> what is even worst, is that even after removing those correct CM, and >>>>>>>> doing a GC etc...they still don't disappear. >>>>>>>> >>>>>>> There is >>>>>>> >>>>>>> ScriptLoader new cleanUpMethods >>>>>>> >>>>>>> This is called from #cleanUpForRelease and normally should make sure >>>>>>> there >>>>>>> are no old methods. >>>>>>> >>>>>> hehehehe if I do: ScriptLoader new cleanUpForRelease, then inspect >>>>>> ((CompiledMethod allInstances select: [:each | each trailer kind = >>>>>> #VarLengthSourcePointer] ) ) >>>>>> >>>>>> they are not GC'ed and if then I click on the first element in the >>>>>> inspector.... VM CRASH!!! with both, InterpreterVM and CogVM. >>>>>> >>>>>> :( >>>>>> >>>>> okay. it seems i found the offender. Its a CompiledMethod >>>>> class>>cleanUp. >>>>> It changing a source pointer of all non-installed methods to 0. >>>> Good catch!!! :) Anyway, why CompiledMethod class>>cleanUp would like >>>> to >>>> destroy source pointers??? >>>> If I understood correctly (please correct me), all compiled methods will >>>> loose the pointer to sources and hence they will be decompiled after when >>>> they are ask their source! >>> Yes, if you wipe the sourcePointer, there is no way how you can get a >>> source code of method. >> I believe the "not getting the source code" was on purpose. >> It's done f.ex. as part of condenseChanges, as the source pointers would >> have been invalid anyways. >> The intent I believe is that you should get decompiled source if you inspect >> old(but still referenced) CompiledMethods, instead of a bogus display of >> some random part of the new changes file, and remove error handling in >> source lookup where pointer could potentially be beyond end of file. >> >> This of course worked much faster before trailers, when setSourcePointer: >> actually modified the instance inline, rather than become'ing a copy, >> nowadays I agree with Igor that it'd probably be more conceptually clean to >> the empty MethodTrailer in destroySourcePointer :) >> >> Just remember to make sure such instances decompile as expected to uphold >> why the zapping was done in the first place. >> If we're lucky, it won't crash the VM either ;) >> > Actually , in #destroySourcePointer setting sourcePointer = 0 is pretty useless. > Since now, we can embed source code in trailer, we can replace a > senders of it with #dropSourcePointer. > Then you don't have to decompile the method, even if its no longer > installed and cannot be located in .sources or .changes files anymore. You are forgetting, the send to #destroySourcePointer happens as a manual step AFTER sources have been truncated. So, trying to move it's source to a trailer from the changefile will be a rather bad idea, as the source at its old pointer is either garbage, or simply out of bounds of the change file already. > We could even do this at the method installation time: > - if a newly installed method replacing an old one, > we tell old one to drop its source pointer immediately. > > Then, by definition, you cannot have non-installed methods with wrong > source pointer, and all those methods will still be able to show you > an original source code. > > Sounds like an idea? This would be the alternative, yes. Not sure if it's worth it, as the source will still be valid as long as change file isn't messed with. 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

May 12, 2011

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

by Guido Chari

I port the plugin to VisualSmalltalk and we have it working well (not heavily tested) for half a year. I could help on this project on the plugin part (for windows and unix only) and on the image side. The problem is that i'm going on vacaction on next weeks so i shall participate only since mid-June. Also i have not too much free time. Anyway i will be interested on using and testing it. Guido 2011/5/10 Sven Van Caekenberghe <sven(a)beta9.be> > 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] legal counsel for pharo?

by StÃ©phane Ducasse

Randall what is the position of squeak regarding the inclusion of qwak code in squeak? Stef On May 12, 2011, at 3:11 AM, Randal L. Schwartz wrote: > > A question recently came up on the squeak-dev mailing list about the > legality of including GPL code in Squeak core, as to where the line > might be. This is especially interesting because of the OpenQwaq > release recently. > > I was able to answer the question for Squeak core definitively by saying > "if you have questions, Squeak is part of the SFC, so we have legal > representation through the SFLC". This permits potential contributors > to get free legal advice about whether their code would be permitted > into Squeak core without violating the Apache/MIT license. > > Which got me wondering, for Pharo, what's the equivalent? Have you guys > retained a lawyer or other arrangements for which you can sort out > license issues? Who is the "SFLC" equivalent for Pharo? > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion >

May 12, 2011

Re: [Pharo-project] About CompiledMethod category returning nil sometimes

by Markus Fritsche

2011/5/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Stef. From what I can see, the category can be nil only when > CompiledMethods are created for DoIts but not for regular CompiledMethods. > Even those which are under 'as yet unclassified'Â answer that and not nil. I think there are some .mcz-s flying around that cause a nil category on load - is that unrelated?

May 12, 2011

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

by Rob Withers

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

[Pharo-project] OCompletion

by Benjamin

Hi everyone, I have just a stupid question but how can I load OCompletion ? I've tried to load packages but I just got a tons of DNU ... Is there a magic formula somewhere over the web ? Thanks in advance, Ben

May 12, 2011

[Pharo-project] Mailinglist archive not working

by Torsten Bergmann

Looks like the mail archive is not working: See http://lists.gforge.inria.fr/pipermail/pharo-project/2011-May/date.html last mail is from May 10 13:44:40 Anyone able to tell the inria admins... Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

May 12, 2011

Re: [Pharo-project] Helvetia... in Squeak

by Lukas Renggli

Hi Frank, See my answers below inbetween your mail: > I've been playing around trying to get Helvetia working in Squeak. It's... > not going well. So I thought I'd try get it working in Pharo, so I could > play around with Helvetia - the point of the exercise - rather than futzing > with porting issues. I suggest that you download the one-click distribution from http://scg.unibe.ch/research/helvetia or the image from my build server (they should be identical). Loading the code manually doesn't work at the moment, because RB, OB, eCompletion and the other dependencies evolved in the meantime and are not compatible with Pharo 1.1.1 anymore. > Now I've tried loading Helvetia into a Pharo 1.1.1 image (old, I know, but > Helvetia says that it wants a 1.1 image), but things don't work too well - I > have issues like OBPluggableShoutTextMorph not understanding #setText:, > leaving me unable to open an omnibrowser. "Browser open" still works, but of > course senders-of and implementors-of are all smashed for the > afore-mentioned reason. Helvetia only works in Pharo 1.1.1 images with the dependencies that were available at that time. > Now I see you have Hudson build scripts for Helvetia, so clearly you've not > abandoned the project, so how do you do things? What base image do you use? > A Pharo 1.3? The builds are not running anymore. Helvetia is based on Pharo 1.1.1. I don't have the time to maintain the codebase. > If/when I get it working, would you be open to the idea of me working to > separate Helvetia's dependencies on things like Polymorph, OB, etc. so I can > use Helvetia in Squeak? Helvetia is all about integrating with tools, which means not only the compiler but also the editors, syntax highlighting, code completion, refactorings, etc. Moving Helvetia from Pharo 0.9 to Pharo 1.1 was a lot of work, because the loader needs to replace the compiler and introduce all kinds of subtle hooks into the running system. I doubt it is possible to get a working version of Helvetia in Squeak without a significant amount of work. After all, only outdated or forked versions of RB, OB, eCompletion, Shout, ... work in Squeak. Also --- and that would be probably the fist and most important step --- you would need to make PetitParser, RB, AST-Compiler, and QuasiQuote work in Squeak. These are the base compilation-related packages required by Helvetia. HTH, Lukas -- Lukas Renggli www.lukas-renggli.ch

May 12, 2011