- Pharo-dev - lists.pharo.org

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

by Tudor Girba

Hi, On 12 May 2011, at 16:30, Marcus Denker wrote: > > On May 12, 2011, at 4:10 PM, Tudor Girba wrote: > >> 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? >> > > Which version of Pharo are you using? It is Pharo 1.2.1. Cheers, Doru >> 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." >> >> >> >> >> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "Beauty is where we see it."

May 12, 2011

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

by Tudor Girba

Hi Henrik, On 12 May 2011, at 16:30, Henrik Sperre Johansen wrote: > On 12.05.2011 16:10, Tudor Girba wrote: >> 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 > Doru, I have NO idea what Morph GLMTabulator uses to display text, nor any desire of spending time trying to (maybe even succesfully) load Glamour. > When posting snippets like that to the Core dev list, at least, PLEASE, either include a doit to load the components needed to reproduce the provided case, or reduce it to something which can be reproduced in core. > > | 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)) asMorph openInWorld > > Works just fine, for example. Thanks for looking into this. I did not mean that someone should look into the posted code. I was in a hurry and I simply asked a direct question if anyone has any idea of why 4096 would be a limit for highlighting text in TextMorph. The question had nothing to do with Glamour, but I am sorry if the form of the mail made you waste your time. In any case, I will look into this in more details. Cheers, Doru > Cheers, > Henry > -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

May 12, 2011

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

by Rob Withers

Hi Sven, 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. Rob -----Original Message----- From: Sven Van Caekenberghe Sent: Thursday, May 12, 2011 10:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations Hi Rob, On 12 May 2011, at 15:52, 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? This looks like a quite impressive code base. I think I once heard about this, but never really looked at it. If I understand this correctly, browsing in SqueakSource, this is actually an SSL implementation, 100% done in Smalltalk ? Some questions then: - in what state is the code, does it work ? - how compatible is it wrt SSL standards ? - how fast is it, is it useable ? - why was it not used for SqueakSSL ? Sven

May 12, 2011

Re: [Pharo-project] [squeak-dev] [BUG][FIX] CompiledMethodTrailer

by Igor Stasenko

On 10 May 2011 13:56, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, May 10, 2011 at 1:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Okay, seems like i found the bug. >> >> >> (CompiledMethodTrailer new sourcePointer: 0) testEncoding >> >> fails. >> >> And it happens only when you pass 0 as source pointer!! >> Such an obscure case! > > > So...this means that after a day and a half of work of the whole community > we finally fix it??Â I am happy. Thanks Igor and the rest who helped as well > :) > > Now...I am not sure if I understand. I saw your changes and you test. But my > question is what happen with those incorrect CM that are arround. It means > that the next build image, when it does the CompiledMethod cleanUp and > destroy the sourcePointers, I will let correct CMs ?Â Does it mean that if I > build a dev image now with such fix, I won't have these weird CMs bothering > me? > Ok....I am trying now.... > Of course they will bother you, because they will hang around if there are closures referencing them > Thanks a lot to everybody for the effort, > > Mariano > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

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

by Rob Withers

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? 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] [MethodTrailer] #getSourceCodeBySelector: and #getSourceCodeByIdentifier: are not implemented

by Marcus Denker

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.

May 12, 2011

Re: [Pharo-project] OCompletion

by Mariano Martinez Peck

Try: http://book.pharo-project.org/book/PharoTools/OCompletion/?_s=vZFSHqszRaNX3… but version 1.3 I guess. On Thu, May 12, 2011 at 4:05 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > 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 > > > > > > -- Mariano http://marianopeck.wordpress.com

May 12, 2011

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

by Marcus Denker

On May 12, 2011, at 4:10 PM, Tudor Girba wrote: > 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? > Which version of Pharo are you using? > 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." > > > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 12, 2011

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

by Henrik Sperre Johansen

On 12.05.2011 16:10, Tudor Girba wrote: > 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 Doru, I have NO idea what Morph GLMTabulator uses to display text, nor any desire of spending time trying to (maybe even succesfully) load Glamour. When posting snippets like that to the Core dev list, at least, PLEASE, either include a doit to load the components needed to reproduce the provided case, or reduce it to something which can be reproduced in core. | 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)) asMorph openInWorld Works just fine, for example. Cheers, Henry

May 12, 2011

[Pharo-project] [ANN] VB-Regex patch available

by Nicolas Cellier

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

May 12, 2011