- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PHP Fog ...

by Nick Ager

there's always EC2 and Gemstone: http://www.vimeo.com/18375790 On 11 January 2011 09:19, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > I reckon a Smalltalk-type Heroku/PHP Fog > ( > http://techcrunch.com/2011/01/10/php-fog-raises-1-8-million-to-be-the-herok… > ) > would be nice :) Would there be a viable business opportunity there or is > the market simply too small? > -- > View this message in context: > http://forum.world.st/PHP-Fog-tp3208657p3208657.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 11, 2011

Re: [Pharo-project] Issue 3471 in pharo: [Failing Test] OBCmdAutoCategorizeWithAMCTest.testOBAutocategorizeCommandOverride

by pharo＠googlecode.com

Updates: Status: Started Comment #4 on issue 3471 by laurent.laffont: [Failing Test] OBCmdAutoCategorizeWithAMCTest.testOBAutocategorizeCommandOverride http://code.google.com/p/pharo/issues/detail?id=3471 In Inbox: SLICE-Issue-3471-Failing-Test-OBCmdAutoCategorizeWithAMCTesttestOBAutocategorizeCommandOverride-LaurentLaffont.1 Fix commands by declaring needed pragmas. Comment + test reorganization from Pharo coding-dojo in Annecy :)

Jan. 11, 2011

Re: [Pharo-project] Why Sets need to be rehashed when loading them from an ImageSegment?

by Mariano Martinez Peck

On Mon, Jan 10, 2011 at 5:35 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Any object that uses an identity hash anywhere in its #hash might > the problem is what that "might" you talk, is about. After Igor example, I understood that the only reason a Set has to be rehashed after an image segment is those objects that are tricky and that RefereceStream does magic to read them. For example, if in a Set instance included objects like nil, true, false, when loaded back, it will point to those objects but those that are present in the image where the loading occurs (some instances like true, false, and nil were not even written in the file when using reference stream). And here, the hashes of those objects can be different from the one where I wrote the Set (like symbols). And the same happens with Symbols. But is it correct that it only happens with these kind of objects? (mostly where ReferenceStream needs a #readXXX method?) Because with the rest of the objects (classes) I don't see any problem since #identityhash cannot change. If all these is correct, then the problem is not that some objects of the Set might have changed its hash, but instead, some objects of the Set are directly REPLACED by other instances (like symbols, true, false, nil, etc) which of course, can have different hashes. Thanks! Mariano > change its hash, thus the rehashing. > > Lukas > > On Monday, 10 January 2011, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi. I was almost sure that Set instances that were written in an > ImageSegment, needed to be rehashed once they are swap in. And I even > thought I was understanding why. But now, I don't understand at all why is > that. I would really appreciate anyway that can give me a hint. > > > > So...ImageSegment rehashes all Set instances (at loading time) that were > written in an ImageSegment, and then exported with ReferenceStream. Notice > that this rehash is finally called from ImageSegment >> comeFullyUpOnReload: > smartRefStream. > > When you export an ImageSegment with a reference stream, you also > serializer the "outPointers" array. This is usually the case when you want > to load the object subgraph in another image or when do it backups so that > to start with a clean image. Notice that the Set rehash only occurs in this > case. If we use ImageSegment just to swap out / in, there is no Set rehash. > > So...I think that this has something to do about WHY Set instances need > to be rehashed. > > > > For each object ImageSegment write into the file, it writes both: object > header + slots. So....the hash (12 bits in the object header) is copied. > When the object is loaded back, it continues to have the same hash. It > doesn't change. > > So...if hash doesn't change, why Set instances need to be rehashes when > they come back from an ImageSegment? > > > > Thanks in advance, > > > > Mariano > > > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Jan. 11, 2011

Re: [Pharo-project] Why Sets need to be rehashed when loading them from an ImageSegment?

by Mariano Martinez Peck

On Mon, Jan 10, 2011 at 1:25 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > One example: > > #foo identityHash in one image > and same #foo identityHash > in another image could be different, because > these symbols could be interned in different time(s). > So, if you have a identity set or identity dictionary which using > symbols as keys, > which is often the case , you need to rehash them. > > Just tried it > image 1 > #awdqedqwd identityHash 633602048 > image 2 > #awdqedqwd identityHash 398196736 > > note that i specifically picked the symbol, which is not yet interned > (not exists) in image. > Obviously, you cannot change the identityHash of symbol(s) which > already present in image, > because you don't know where it used outside of object(s) you are loading. > > Uhhhhhh this was a good example ;) I forget about this guys heheh Thanks Igor. This is a clear example. > > On 10 January 2011 10:51, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi. I was almost sure that Set instances that were written in an > > ImageSegment, needed to be rehashed once they are swap in. And I even > > thought I was understanding why. But now, I don't understand at all why > is > > that. I would really appreciate anyway that can give me a hint. > > > > So...ImageSegment rehashes all Set instances (at loading time) that were > > written in an ImageSegment, and then exported with ReferenceStream. > Notice > > that this rehash is finally called from ImageSegment >> > comeFullyUpOnReload: > > smartRefStream. > > When you export an ImageSegment with a reference stream, you also > serializer > > the "outPointers" array. This is usually the case when you want to load > the > > object subgraph in another image or when do it backups so that to start > with > > a clean image. Notice that the Set rehash only occurs in this case. If > we > > use ImageSegment just to swap out / in, there is no Set rehash. > > So...I think that this has something to do about WHY Set instances need > to > > be rehashed. > > > > For each object ImageSegment write into the file, it writes both: object > > header + slots. So....the hash (12 bits in the object header) is > copied. > > When the object is loaded back, it continues to have the same hash. It > > doesn't change. > > So...if hash doesn't change, why Set instances need to be rehashes when > they > > come back from an ImageSegment? > > > > Thanks in advance, > > > > Mariano > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Jan. 11, 2011

[Pharo-project] PHP Fog ...

by Geert Claes

I reckon a Smalltalk-type Heroku/PHP Fog (http://techcrunch.com/2011/01/10/php-fog-raises-1-8-million-to-be-the-herok…) would be nice :) Would there be a viable business opportunity there or is the market simply too small? -- View this message in context: http://forum.world.st/PHP-Fog-tp3208657p3208657.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 11, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by Igor Stasenko

On 11 January 2011 09:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > but igor for example in the case of soul, it means that you should load the SoulCompiler which is > normal if you want to use soul compiled methods. > Now having a reference to a class makes static warning easier than just an object. > >From that perspective it doesn't makes any difference: referencing a missing class in #compilerClass, or in #newCompiler would lead to same error/warning. What makes these approaches different is where you controlling the creation and initialization of compiler instance. > Stef > > On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote: > >> On 10 January 2011 20:52, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> Parser is not hardcoded (except in tests), but parserClass is >>> sometimes sent to the wrong class.. >>> Example is Text>>makeSelectorBold (sent from Debugger) >>> It should be replaced with makeSelectorBoldIn: >>> >>> Also notice that source code files cannot be analyzed if they contain >>> classes absent from current system that define their own parserClass. >>> That is a problem for change lists, and possibly for MC (it would be >>> interesting to try). >>> >> >> I think that there could be a solution to that. >> We could require that certain methods like #newParser, #newCompiler >> should be written in smalltalk. >> Then code import tools could rely on that and compile these methods >> first, and then could use them to compile the rest of class'es source >> code. >> >> >>> Nicolas >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 11, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by StÃ©phane Ducasse

but igor for example in the case of soul, it means that you should load the SoulCompiler which is normal if you want to use soul compiled methods. Now having a reference to a class makes static warning easier than just an object. Stef On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote: > On 10 January 2011 20:52, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Parser is not hardcoded (except in tests), but parserClass is >> sometimes sent to the wrong class.. >> Example is Text>>makeSelectorBold (sent from Debugger) >> It should be replaced with makeSelectorBoldIn: >> >> Also notice that source code files cannot be analyzed if they contain >> classes absent from current system that define their own parserClass. >> That is a problem for change lists, and possibly for MC (it would be >> interesting to try). >> > > I think that there could be a solution to that. > We could require that certain methods like #newParser, #newCompiler > should be written in smalltalk. > Then code import tools could rely on that and compile these methods > first, and then could use them to compile the rest of class'es source > code. > > >> Nicolas >> > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 11, 2011

Re: [Pharo-project] [squeak-dev] Re: new Cog VMs

by Igor Stasenko

On 11 January 2011 04:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, Â Hi All, > > On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 3 January 2011 00:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > Hi Martin, Hi All, >> > Â Â Â so find new VMs inÂ VM.r2341/. Â The linux crashes (certainly the one >> > you >> > suffered from Martin) seem to be caused by an optimization bug (but they >> > could be caused by bad code generation, creating something that assumes >> > ordering constraints which C doesn't guarantee). Â I suspect the former >> > because I don't see the crash when running exactly the same VM and image >> > from a different directory; provoking the crash requires a particular >> > path >> > (go figure; I haven't pinned this down yet). >> > So my "fix" is preventing a complex function being inlined into the main >> > interpreter loop, removing the sources of some warnings, and lowering >> > the >> > optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my >> > build >> > environment, CentOS Linux 5.3, uses gcc 4.1.2). Â I'm not proud of this >> > "fix". Â I've violated the Deutsch criterion by not diagnosing the cause >> > of >> > the bug so I can't stand behind this fix; it's a hack that appears to >> > work >> > and may have merely pushed the real bug further underground. Â Alas I >> > don't >> > have time to do a better job. Hopefully it'll get those of you on linux >> > going again. >> >> Eliot, if you remember, i also had crash issues on linux, and pinned down >> it to >> removing optimization from <something>heartbeat.c while keeping >> gcc3x-cointerp.c to use >> Â same optimization flags as for rest of files. > > Indeed, quite right. Â I happened to add a flag to turn off the heartbeat so > I could debug the crash Matthew was seeing in starting up > Squeak4.2-10856-beta.image (since single-stepping through machine code > always gets interrupted by the heartbeat, it being an interval timer) and lo > and behold the bug went away. Â This is very worrying because it appears to > imply that there's a serious bug in the linux kernel/gcc since delivering a > software interrupt shouldn't corrupt registers, but it clearly does. Â I'll > try and pass it by someone who's an expert in this area. > Anyway, now find a new linux VM inÂ VM.r2346/Â that seems fine with the > interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2. > Â Running this VM on CentOS 5.3 under Parallels I get > Â Â Â 2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0 > unexpected passes > for the full test suite inÂ Squeak4.2-10856-beta.image. > So have at it. Great! Nice to see that we can deal with elusive bugs :) > best > Eliot >> >> I will start coding cmake config for Cog during next week and will be >> able to check my previous >> observations again. >> >> > best >> > Eliot >> > On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic(a)gmail.com> wrote: >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Jan. 11, 2011

Re: [Pharo-project] Origins [poll]

by StÃ©phane Ducasse

Jan. 11, 2011

Re: [Pharo-project] [squeak-dev] Re: new Cog VMs

by Andres Valloud

> Indeed, quite right. I happened to add a flag to turn off the heartbeat > so I could debug the crash Matthew was seeing in starting up > Squeak4.2-10856-beta.image (since single-stepping through machine code > always gets interrupted by the heartbeat, it being an interval timer) > and lo and behold the bug went away. This is very worrying because it > appears to imply that there's a serious bug in the linux kernel/gcc > since delivering a software interrupt shouldn't corrupt registers, but > it clearly does. I'll try and pass it by someone who's an expert in > this area. Or the signal handler functions do not comply with the relevant specifications, e.g.: signal handlers that do not preserve the value of errno, signal handlers that use a function not in the list of approved safe functions you can call from a signal handler as per the Single Unix Specification, etc... Andres.

Jan. 11, 2011