September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b10

by StÃ©phane Ducasse

Thanks John Stef > I've stuck a version (5.8b10) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b10.app.zip > > Changes are: > > (a) Fix issue with timezone calculation on file creation and modification timestamps. > (b) Fix a crash with sqInt ioSetCursor() which calls ioSetCursorWithMask() with a NULL mask value which it did not handle correctly. > > Based on feedback I wil produce a non-cog VM 5.7x and push that as the approved for regular use os-x/iOS VM on the weekend. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b10

by John M McIntosh

I've stuck a version (5.8b10) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b10.app.zip Changes are: (a) Fix issue with timezone calculation on file creation and modification timestamps. (b) Fix a crash with sqInt ioSetCursor() which calls ioSetCursorWithMask() with a NULL mask value which it did not handle correctly. Based on feedback I wil produce a non-cog VM 5.7x and push that as the approved for regular use os-x/iOS VM on the weekend. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 9, 2010

Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1

by StÃ©phane Ducasse

why should add some guards in the tests for that even if ObjectAsMethods is a cool feature to have for experimentation. There are some changes from squeak pending in the bug tracker. Now you should also pay that the coverage button is using wrapper and I guess also use test coverage. Stef > Hi: > > I was playing a bit with a stock Pharo 1.1 image, with the only adding > of the cs NecessaryImageChangesForCogToWork.Pharo1.1. > > Then I tried to run TestRunner new runAll (for comparing times against > the common vm) and get the attached segfault. > > I tried with my own compiled cog and also with the downloaded from > here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. > > My OS is Ubuntu 10.04 64 bits. > > Any hint will be appreciated. > > Cheers. > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > <cogsegfault.txt>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

by John M McIntosh

On 2010-09-09, at 8:21 AM, Philippe Marschall wrote: >> There is also issues withe currency symbol, the logic assumes it's one byte, but it could be a unicode value >> if you decide between the international symbol versus localized regional symbol. I think the plugin is flawed >> in that respect. > > Answers 'SFr.' where quite nicely. > > Cheers > Philippe Ok I've placed a LocalePlugin 2.1b1.bundle.zip on the server. It has a minor fix where I did the length calculation in UTF8 then asked for the data in MacRoman. Must not write email when tired. It's the currency decimal and grouping separators that are fixed as 1 byte. Also currency uses the international symbol(s) in UTF8 versus the regional value which might be different and at some different point in the unicode chart. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 9, 2010

Re: [Pharo-project] CompiledMethod

by Mariano Martinez Peck

Hi Benjamin. Yes, this is a known "problem". Check http://forum.world.st/problem-with-CompiledMethod-equality-tt2221276.html#a… 2010/9/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/9/9 Benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> > > Hi everybody, >> >> >> I wonder if it's normal than two different methods can have the same >> CompiledMethod ? >> >> By example : >> >> Class >> foo >> 'foo' >> >> and >> >> Class >> foo2 >> 'foo' >> >> If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), >> it answers true. >> >> Maybe the CompiledMethod >> = should test the source ? >> > > There are many definitions of method equality. If you ant to test the > source you can test the source, (C >> #foo) getSourceFromFile asString = (C > >> #foo2) getSourceFromFile asString. You can test the decompilation of a > method (C>>#foo) decompileString = (C>>#foo2) decompileString. > > The current definition tests whether the bytecodes and literals are the > same, not the selector or the source code. That's a useful definition, but > not the only one. It is close to the decompile version but faster, and is > useful in e.g. testing whether the compiler has changed, since if on > recompiling a method is still = the compiler is producing the same bytecode > for a compilation. That's what I use it for and it's an important use. > > cheers > Eliot > > >> >> >> Ben >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

Re: [Pharo-project] DateAndTimeTest failures

by StÃ©phane Ducasse

Thanks Pavel I have been thinking a lot about you recently. I started to create a lot of bug entries remodularisation (and I got trapped by time - today an obligatory meeting starting a 12h on account certification :) and ended up at 17h :) I will continue and I saw to nicolas and gabriel how they can help going over your issues and the new ones I'm creating. Stef On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: > Hi, > > I tried to fix DateAndTimeTest failures, see > http://code.google.com/p/pharo/issues/detail?id=2936 > > The patch adds methods clearOffset and withoutOffset to DateAndTime. > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] simpleLog in pharo?

by Schwab,Wilhelm K

GÃ¶ran, Re "left running," while it is not my intention to throw up the knee-jerk "NO" that has been so common in other projects, I do think we should demand a torture test of any logging system that we adopt. If it can't be started and safely forgotten, it isn't ready. Is the code base small because it is simple and elegant (good) or because it is missing a lot of functionality to let it pass the set and forget test? I don't know the answer, but the question must be asked, and my vote is to adopt only after the answer is favorable. Your observation about new tools is well taken. Your experience on an old laptop is very interesting. If you really want to watch a struggle, compare Pharo to Dolphin running across a remote desktop connection. I am no Morphic expert, but it makes me wonder just how much of the screen is being redrawn and whether a lot of that could be avoided. Good performance on modest hardware is of value. You mention "shiny new stuff," but that is largely in the IDE or parallel systems (e.g. Nile, Ocean). The alternative is to continue to languish with Squeak's streams, sockets, file system, etc. Parts of Squeak are the way they are because they predate structured exception handling. Pharo is catching up on 15 years of refactoring to take advantage of 25 years of advancing technology. There will be some instability along the way, but the released versions have been pretty good so far. No doubt we can and should do better as Pharo evolves. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of GÃ¶ran Krampe [goran(a)krampe.se] Sent: Wednesday, September 08, 2010 7:34 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? Hi! On 09/09/2010 01:18 AM, Schwab,Wilhelm K wrote: > GÃ¶ran, > > I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. > That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small. Secondly - my impression of Pharo so far is not really "robust", and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop. It seems to me that "progress" (new shiny stuff!) has been put in favor of robustness, which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release? Sorry for that little rant, don't really "mean" anything with it, just curious to see if I am the only one with this feeling. > On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think. > > On Linux, you mention lots of tools: any recommendations? No :). But there are lots of syslog related tools, just google it. :) regards, GÃ¶ran _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] CompiledMethod

by Eliot Miranda

2010/9/9 Benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> > Hi everybody, > > > I wonder if it's normal than two different methods can have the same > CompiledMethod ? > > By example : > > Class >> foo > 'foo' > > and > > Class >> foo2 > 'foo' > > If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), > it answers true. > > Maybe the CompiledMethod >> = should test the source ? > There are many definitions of method equality. If you ant to test the source you can test the source, (C >> #foo) getSourceFromFile asString = (C >> #foo2) getSourceFromFile asString. You can test the decompilation of a method (C>>#foo) decompileString = (C>>#foo2) decompileString. The current definition tests whether the bytecodes and literals are the same, not the selector or the source code. That's a useful definition, but not the only one. It is close to the decompile version but faster, and is useful in e.g. testing whether the compiler has changed, since if on recompiling a method is still = the compiler is producing the same bytecode for a compilation. That's what I use it for and it's an important use. cheers Eliot > > > Ben > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

[Pharo-project] CompiledMethod

by Benjamin Van Ryseghem

Hi everybody, I wonder if it's normal than two different methods can have the same CompiledMethod ? By example : Class >> foo 'foo' and Class >> foo2 'foo' If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), it answers true. Maybe the CompiledMethod >> = should test the source ? Ben

Sept. 9, 2010

[Pharo-project] DateAndTimeTest failures

by Pavel Krivanek

Hi, I tried to fix DateAndTimeTest failures, see http://code.google.com/p/pharo/issues/detail?id=2936 The patch adds methods clearOffset and withoutOffset to DateAndTime. Cheers, -- Pavel

Sept. 9, 2010