May 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] New transcript questions and notes (take 2)

by DougEdmunds

[Yesterday I posted this on Nabble, and deleted it, because it wasn't processing (apparently the mail server was down). That's a mistake. Now it's in the mailing list archive, but the Nabble entry http://forum.world.st/New-transcript-questions-and-notes-tp3516546p3516546.… is gone, which means it may not garner a reply.] So, with apologies, I repeat: Using Pharo1.3a Latest update: #13193 Are there any plans to give the new transcript window a mouseable menu? If not, buttons for select all and copy would be nice. -- Nothing seems to be happening when clicking 'log to file'. What is the name of the file? Where is it? -- When checking/unchecking/checking 'log to file' will the second checking add to the end of an existing file, or will it start a new one, or wipe out old one and start it over? -- This code does not work right with the new transcript: 1 to: 30 do: [: x | Transcript cr; show: x. (Delay forSeconds: 0.2) wait.]. a) Try it in 1.2 (old transcript) to see how it should work. Old transcript, there's a delay between each line printed. 1.3 (new transcript) there's a total delay first, then all the lines are immediately printed. b) If the length of the entries to the transcript exceeds the size of the window, the lines do not automatically scroll up to be able to see them. Instead, they are added outside of the visible window area. IMO, this must be changed so that whatever gets added to the end of the transcript is immediately visible. c) If cursor is at the bottom (with a vertical scroll bar visible), as soon as a new line is added, the transcript pops back to the beginning again, requiring scrolling to see new entries. This makes any kind of continual stream to the transcript impossible to view. Position the Transcript at the end of the output, then run the 1 to: 30 do: code line again -- it will pop you to the top, not the end. -- Will the vertical size of the header area (Clear, etc) be reduced? It is taller than needed. -- View this message in context: http://forum.world.st/New-transcript-questions-and-notes-take-2-tp3517942p3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 12, 2011

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

by Tudor Girba

I thought that Helvetia also works in Pharo 1.2.1. At least I saw that Bifrost is using it. Am I wrong? Cheers, Doru On 12 May 2011, at 17:43, Lukas Renggli wrote: >>> The builds are not running anymore. Helvetia is based on Pharo 1.1.1. >>> I don't have the time to maintain the codebase. >> >> That's a pity, it was/is quite impressive (I read your paper, have your PhD on my reading list). >> >> But I understand. > > It is a lot of work. It took me more than 1 year (about 1 month of > full time) to move Helvetia forward from Pharo 0.9 to 1.1. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

May 12, 2011

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

by Lukas Renggli

>> The builds are not running anymore. Helvetia is based on Pharo 1.1.1. >> I don't have the time to maintain the codebase. > > That's a pity, it was/is quite impressive (I read your paper, have your PhD on my reading list). > > But I understand. It is a lot of work. It took me more than 1 year (about 1 month of full time) to move Helvetia forward from Pharo 0.9 to 1.1. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 12, 2011

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

by Tudor Girba

Hi, On 12 May 2011, at 17:19, Damien Cassou wrote: > 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. I see the intent but I think this is done at the wrong level, because like this we have no way to highlight something even if we would be willing to wait. Cheers, Doru > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

May 12, 2011

Re: [Pharo-project] [squeak-dev] [NativeBoost] Need your ideas, what platform-neutral assembler syntax you would like to have

by Igor Stasenko

On 12 May 2011 17:22, Gerardo Richarte <gera(a)corest.com> wrote: > On 05/10/2011 08:34 PM, Igor Stasenko wrote: >> Things i don't like: register naming. >> In cog you should use following register names: >> Â Â Â FPReg := -1. >> Â Â Â SPReg := -2. >> Â Â Â ReceiverResultReg := GPRegMax := -3. >> Â Â Â TempReg := -4. >> Â Â Â ClassReg := -5. >> Â Â Â SendNumArgsReg := -6. >> Â Â Â Arg0Reg := -7. >> Â Â Â Arg1Reg := GPRegMin := -8. >> Â Â Â DPFPReg0 := -9. >> >> They are mapping 1:1 to real registers on your machine. > > "Our" names are pretty similar to those, and I don't really see they are > 1:1 mapping to architecture (though at some point you will have that > mapping). The 1:1 mapping is not on names, but latter on implementation, > and I think that has to do with exactly what Cog wants: a fast > implementation. > In Cog TempReg maps to EAX. and rest of register names mapped directly to assembler ones. I don't see how register names could affect an implementation. It depends where and how you using them. I agree that when you generating code which closely related to VM internals, then it makes sense to use special names like SendNumArgsReg. But if you wanna use spare register to hold something else than NumArgs.. then using such name is not helping. In that cases, i would prefer to use neutral names, like GPReg0 ... GPRegX .. which stands for General Purpose Register. Because the role of certain register may be different depending on where you using it. > FP is frame pointer, and it's the generic name for what in intel is BP > (in gdb you can do either $rbp or $fp) > SP is a generic name for the stack pointer (in gdb you can use $sp or $rsp) > ReceiverResult has to do with the use, nothing to do with processor > etc. > > not sure what DPFPReg0 stands for. > I guess its a "Double Precision Floating Point Register number 0" :) > I think the names are good for a VM implementation. Though maybe not for > a generic assembler. I think the that might be the difference between > Cog's and NativeBoost's needs > Yes. This is why i asking.. Because i want it to be generic. > Â Â gera > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

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