- Pharo-dev - lists.pharo.org

Re: [Pharo-project] compiled VM with Alien for JNIPort

by Igor Stasenko

On 10 May 2011 22:27, laurent laffont <laurent.laffont(a)gmail.com> wrote: > So following Mariano's blog and pharocasts I've built Cog with IA32ABIPlugin > (works, cool !) > When starting the JVM following JNIPort instructions on SqueakSource wiki, > the VM crashes. > GDB bt gives: > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 > 0x00000000 in ?? () > (gdb) bt > #0 Â 0x00000000 in ?? () > #1 Â 0x000d267a in primCallOutIntegralReturn () at > /Users/laurentlaffont/dev/pharo/vm/blessed/src/plugins/IA32ABI/IA32ABI.c:500 > #2 Â 0x00023a3e in interpret () at > /Users/laurentlaffont/dev/pharo/vm/blessed/src/vm/gcc3x-cointerpmt.c:2037 > #3 Â 0x962ede02 in __CFRunLoopDoObservers () > #4 Â 0x962a9d8d in __CFRunLoopRun () > #5 Â 0x962a9464 in CFRunLoopRunSpecific () > #6 Â 0x962a9291 in CFRunLoopRunInMode () > #7 Â 0x934dce04 in RunCurrentEventLoopInMode () > #8 Â 0x934dcaf5 in ReceiveNextEventCommon () > #9 Â 0x934dca3e in BlockUntilNextEventMatchingListInMode () > #10 0x9644778d in _DPSNextEvent () > #11 0x96446fce in -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] () > #12 0x96409247 in -[NSApplication run] () > #13 0x964012d9 in NSApplicationMain () > #14 0x00078247 in main (argc=1, argv=0xbffff680, envp=0xbffff688) at > /Users/laurentlaffont/dev/pharo/vm/blessed/platforms/iOS/vm/Common/main.m:52 > (gdb) > Any idea ? > Laurent. > A smalltalk stack trace would help. As usual, check what you passing to the foreign function. Is everything set up correctly? Because from the above i see that some piece of software accessing null pointer. And this is usually problem with proper initialization or missing error handling. -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

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

by Sven Van Caekenberghe

Hi Jan, On 12 May 2011, at 17:07, Jan van de Sandt wrote: > Hello, > > I can help test the client part of a HTTPS implementation. Currently I use Zinc-HTTP together with stunnel. > > Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is possible to use OpenSSL on windows as well [1]. > > Jan. > > [1] http://www.openssl.org/related/binaries.html That is interesting. Is the VAST plugin open source ? And of course, thanks for the offer, I knew you would be interested ! Sven

May 12, 2011

Re: [Pharo-project] [update 1.2] #12352

by Damien Cassou

On Thu, May 12, 2011 at 8:49 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Issue 4157: Â Â TextColor is ignored in large TextEditors IIRC, this was made on purpose to avoid waiting hours for syntax highlighting to color big regions. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 12, 2011

[Pharo-project] [update 1.3] #13194

by StÃ©phane Ducasse

13194 ----- - Issue 4015: Fix in SmalltalkEditor. Stef

May 12, 2011

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

by Jan van de Sandt

Hello, I can help test the client part of a HTTPS implementation. Currently I use Zinc-HTTP together with stunnel. Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is possible to use OpenSSL on windows as well [1]. Jan. [1] http://www.openssl.org/related/binaries.html On Tue, May 10, 2011 at 7:42 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > 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] [Moose-dev] Re: Highlight problem with glamour

by Tudor Girba

Hi again, On 12 May 2011, at 16:51, Tudor Girba wrote: > Hi, > > On 12 May 2011, at 16:44, Marcus Denker wrote: > >> >> On May 12, 2011, at 4:42 PM, Tudor Girba wrote: >>> >>> 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. >>> >> >> >> maybe this is relevant? We should release 1.2.2.... >> >> http://code.google.com/p/pharo/issues/detail?id=4157 > > Hmm. Sounds similar, but I am too ignorant. > > I could reproduce the problem outside of Glamour. The issue is indeed not with TextMorph, but with PluggableTextMorph: > > string := ''. > 1 to: 1000 do: [:i | string := string, 'abcde']. > text := ((string asText addAttribute: TextColor red), ('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' asText)). > (PluggableTextMorph on: text text: #yourself accept: #value) openInWindow I tried the fix attached suggested in issue 4157 and then my test works fine, so I guess it does fix the problem: http://code.google.com/p/pharo/issues/detail?id=4157 Cheers, Doru > Cheers, > Doru > > >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- > www.tudorgirba.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

May 12, 2011

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

by Marcus Denker

On May 12, 2011, at 4:51 PM, Tudor Girba wrote: > Hi, > > On 12 May 2011, at 16:44, Marcus Denker wrote: > >> >> On May 12, 2011, at 4:42 PM, Tudor Girba wrote: >>> >>> 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. >>> >> >> >> maybe this is relevant? We should release 1.2.2.... >> >> http://code.google.com/p/pharo/issues/detail?id=4157 > > Hmm. Sounds similar, but I am too ignorant. > > I could reproduce the problem outside of Glamour. The issue is indeed not with TextMorph, but with PluggableTextMorph: > > string := ''. > 1 to: 1000 do: [:i | string := string, 'abcde']. > text := ((string asText addAttribute: TextColor red), ('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' asText)). > (PluggableTextMorph on: text text: #yourself accept: #value) openInWindow > works fine in 1.2.2a -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 12, 2011

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

by Sven Van Caekenberghe

Rob, On 12 May 2011, at 16:38, Rob Withers wrote: > 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. It would be *very cool* if that code base could be ported to Pharo. It is really quite impressive that you did all this from the spec. I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc.. Does that sound like a good idea ? Sven

May 12, 2011

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

by Tudor Girba

Hi, On 12 May 2011, at 16:44, Marcus Denker wrote: > > On May 12, 2011, at 4:42 PM, Tudor Girba wrote: >> >> 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. >> > > > maybe this is relevant? We should release 1.2.2.... > > http://code.google.com/p/pharo/issues/detail?id=4157 Hmm. Sounds similar, but I am too ignorant. I could reproduce the problem outside of Glamour. The issue is indeed not with TextMorph, but with PluggableTextMorph: string := ''. 1 to: 1000 do: [:i | string := string, 'abcde']. text := ((string asText addAttribute: TextColor red), ('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' asText)). (PluggableTextMorph on: text text: #yourself accept: #value) openInWindow Cheers, Doru > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

May 12, 2011

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

by Marcus Denker

On May 12, 2011, at 4:42 PM, Tudor Girba wrote: > > 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. > maybe this is relevant? We should release 1.2.2.... http://code.google.com/p/pharo/issues/detail?id=4157 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 12, 2011