- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

On May 12, 2011, at 4:03 PM, Randal L. Schwartz wrote: >>>>>> "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. what is an upstream component? How could openqwak can release a component not GPL if Qwak is GPL? > 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 StÃ©phane Ducasse

On May 12, 2011, at 3:53 PM, Markus Fritsche 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? yes this could be that. >

May 12, 2011

Re: [Pharo-project] [Moose-dev] Re: Highlight problem with glamour

by Tudor Girba

Thanks, Fabrizio. I noticed a similar problem with highlighting Java code, but I thought it was related to the grammar. I CC-ed the Pharo mailing list. Anyone knows why it would be a problem to highlight text with more than 4096 characters in a TextMorph? Cheers, Doru On 12 May 2011, at 16:03, Fabrizio Perin wrote: > It basically breaks after 4096 characters. > > > On 12 May 2011, at 16:02, Fabrizio Perin wrote: > >> Hi, >> i was playing with textlint and i noticed that the highlight is broken. Seems that the problem is related to the length of the text. If you try to execute the script below you notice that the highlight doesn't work. If you lower 1000 to 100 it works. It seems that the break point is 194. After that it dies. >> >> | browser | >> browser := GLMTabulator new. >> browser >> column: #details. >> >> "if you need initial display" >> browser transmit to: #details; andShow: [:a | >> a text display: [:x | >> | string | >> string := ''.1 to: 1000 do: [:i | string := string, 'jjjjj j j j j j jjj j']. >> (string asText addAttribute: TextColor red), ('jjjjj j j j j j jjj j' asText) ] ]. >> >> browser openOn: 5 >> >> Any idea? >> >> Cheers, >> >> Fabrizio >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

May 12, 2011

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

by Guido Chari

VisualSmalltalk runs only on Windows. My port of SqueakSSL is to windows. But i have expierence on Unix too. Never worked on Mac. 2011/5/12 Sven Van Caekenberghe <sven(a)beta9.be> > > On 12 May 2011, at 15:59, Guido Chari wrote: > > > 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 > > That is great, Guido! > > Don't worry, it will take some time, no rush. > > What OS platforms did you work on ? All 3 ? > > Sven > > >

May 12, 2011

Re: [Pharo-project] [update 1.3] #13191

by Mariano Martinez Peck

THanks a lot Fernando!! On Wed, May 11, 2011 at 4:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 13191 > ----- > > - Issue 4177: New TranscriptWindow and several fixes to the (new) > Transcript adoption. Thanks a lot Fernando Olivero. > 3112: ThreadSafeTranscript >> #endEntry is Morphic dependent. > 3948: Transcript and ThreadedTranscript needs to be merged. > 4023: Transcript clear prints Transcript after clearing prior text. > 4039: To open ThreadSafeTranscript . > 4067: Transcript does not work with system fonts (Win XP) > (TranscriptModel>>displayOn: aForm uses StandardFonts now) > 4093: alt_t (fixed by loading the post load: send > initializeDesktopCommandSelectors for the worlds) > 4116: minimizing, then output to transcript: redraw problems. > > > Stef > -- Mariano http://marianopeck.wordpress.com

May 12, 2011

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

by StÃ©phane Ducasse

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] SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations

by StÃ©phane Ducasse

you can in pharoTaskForces or you can create a PharoSSL Stef > 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] SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

by Sven Van Caekenberghe

On 12 May 2011, at 15:59, Guido Chari wrote: > 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 That is great, Guido! Don't worry, it will take some time, no rush. What OS platforms did you work on ? All 3 ? Sven

May 12, 2011

Re: [Pharo-project] OCompletion

by Romain Robbes

Off the top of my head, that should be something like: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load. (Smalltalk at: #ConfigurationOfOCompletion) perform: #loadDefault. Cheers, Romain On Thu, May 12, 2011 at 5:37 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > 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

Re: [Pharo-project] [Pharo-users] Call for ideas for DBXTalk UI

by StÃ©phane Ducasse

For me I would love to see Magritte extended to support pair or collection of elementary data. Stef On May 11, 2011, at 12:39 AM, Mariano Martinez Peck wrote: > Hi guys. Thanks to the ESUG SummerTalk, DBXTalk team has started to work with the new products of the DBXTalk suite. However, for one of the tools in special we would like to hear your opinion. Just a little introduction to the two other tools: > > 1) A new Glorp port from VW to Pharo. In addition, we provide the DBX driver for Glorp, by the name of GlorpDBX. Guillermo Polito is mostly working on this. > 2) A new tool that uses Magritte and the database metadata to automatically generate the mappings between objects and tables. The idea is to do it two-way: > a) read the metadata from an existing database -> create magritte descriptions -> generate Glorp mappings -> query with Glorp > b) write magritte descriptions for the mappings -> generate database schema -> generate Glorp mappings -> query with Glorp > or something like that....it is not completely decided but that's the idea. This way we can autogenerate the Glorp mappings and then use Glorp normally. Santiago Bragagnolo is working mostly on this. > > The third product, and here the question, is going to be a UI for the DBXTalk suite. This UI would do the core functionalities of tools like SQLDeveloper, MySQL Explorer, pgAdmin, etc. This is basically: > - visualize and get information of: tables, views, schemas, relations, indexes, etc. > - be able to modify the previous items and impact them in the database > - write queries and get results > > So...why this tool if we can also use external tools like SQLDeveloper, MySQL Explorer, pgAdmin, etc ? a couple of reasons: > 1) having the tool inside the image is easier (just the same way you sometimes install an Eclipse plugin instead of using such programs) > 2) the same tool works for all databases > 3) we can customize it with particular things of DBX > Gisela Decuzzi is working mostly on this. > > Now....what use cases do you think are useful for such UI ? what kind of things would you like ? what things we can do that are related to Glorp and to the magritte tool? > what things can we do to have even more advantages than just using external programs ? I have the following things in mind: > > - Special console for DBX/Glorp logs. > - Be able to edit Magritte description for mappings. > - Sync the tables and mapping while edditing. > - A new inspector for inspecting restultsets, where you see one rows and columns. > > Let us know. > > Once again, thanks ESUG for the sponsorship to the team. > > > Mariano > http://marianopeck.wordpress.com >

May 12, 2011