February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] test job

by Benjamin

On Feb 28, 2013, at 1:48 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > +1 > > I want everything automatic :) Even the integration process ? :) Ben >>> I made a multidimensional matrix test job running each VM twice >>> >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/ >>> >>> maybe a slight overkill for now, but at least you should spot irregularities easier.. >> >> :-) >> >> I like how a automatic build and a build server at first seems useless >> ("I can do that, too, I don't need that, I compile the VM after changing it anyway"). >> >> And then later it starts that one does things that one could never ever even think >> about doing manually. >> >> Marcus > >

Feb. 28, 2013

Re: [Pharo-project] IslandVMTweaksTestCase and Memory corruption

by Marcus Denker

On Feb 28, 2013, at 3:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > I was looking for VM tests in the Pharo image and I found the class IslandVMTweaksTestCase. The strange thing is its comments : > "Test case for some tweaks to the VM that Islands requires. These tests are largely for documentation; with an un-tweaked VM, the tests mostly still succeed, albeit with possible memory corruption." > > Does that really mean if I run those tests it might result into memory corruption ? > > I don't think it is a good idea to ship Pharo with this memory corruption tests in IslandVMTweaksTestCase. I suggest that if the tests may really corrupt memory we remove them from Pharo, or if they cannot corrupt memory then we fix the memory corruption comment. > Yes, we should not ship code like that. Marcus

Feb. 28, 2013

[Pharo-project] IslandVMTweaksTestCase and Memory corruption

by ClÃ©ment Bera

Hello, I was looking for VM tests in the Pharo image and I found the class IslandVMTweaksTestCase. The strange thing is its comments : "Test case for some tweaks to the VM that Islands requires. These tests are largely for documentation; with an un-tweaked VM, the tests mostly still succeed, albeit *with possible memory corruption*." Does that really mean if I run those tests it might result into memory corruption ? I don't think it is a good idea to ship Pharo with this memory corruption tests in IslandVMTweaksTestCase. I suggest that if the tests may really corrupt memory we remove them from Pharo, or if they cannot corrupt memory then we fix the memory corruption comment. Regards,

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Sean P. DeNigris

tinchodias wrote > Are you talking about an specific pragma for deprecation? I didn't catch > it. I was thinking of something like <safeForMethodFinder>, but agree with Marcus's objection that those would have to be sprinkled everywhere in the system. It solves one problem, but creates another... -- View this message in context: http://forum.world.st/String-asPacked-fromPacked-tp4672413p4672713.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Marcus Denker

On Feb 28, 2013, at 2:17 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 28, 2013, at 2:07 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Marcus Denker-4 wrote >>> (We really need to clean up the MethodFinder, it references a lot of >>> crap). >> >> I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful >> here? >> > I don't know. The small fix we can do immediately. Cleaning MethodFinder needs > serious thought and work, so if that is the issue where will be no progress for a while. > > Let's clean the trivial thing *now* (that is, when 3.0 is started), and add a second > issue for the MethodFinder. > > As for it: it uses positive tagging. "It is ok to run this method as there are no side effects". > Do you want a pragma in *every* method? I don't. > > For things like this we need a way to associate meta data with methods that is a bit less > intrusive, yet stored in a way that it is not lostâ¦ > And maybe it should be part of MethodFinder, not part of the method itself. > If possible it should abstract away from MethodFinder and encode something about side-effectsâ¦ Or one could have some form of sandboxed secure environment to run stuff and it's not a problem if there are side effects. It's all not easyâ¦ doing MethodFinder right is very hard. Up to the point that the trivial thing there is now is the actually the sweet spot? Of course the code is horrible, absolutely horribleâ¦ I even removed it in the development phase of 1.0 once, because it is just ugly and referencing so many symbolsâ¦ but it is a fun demo. Now how can one implement that fun demo "For real"? Having the info that a method can be called safely actually could be interesting for other things, e.g. random testing. http://code.google.com/p/yeti-test/ Marcus

Feb. 28, 2013

Re: [Pharo-project] [Vm-dev] fast #becomeForward: crashes without PharoV10.sources

by Esteban Lorenzano

Hi Eliot, I have a very reproducible case :) just take latest pharo 2.0 image, edit #condenseSources to remove: VirtualMachine isRunningCogit ifTrue: [ self error: 'Sources cannot be condensed in a Cog (JIT enabled) Virtual Machine. Try a Stack VM.' ]. (so it runs it in cog :) and execute Smalltalk condenseSources. BOOM! :) and printAllStacks show that it stopped in #becomeForward: Esteban On Feb 26, 2013, at 7:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > we should reafctor the code for changing the method's trailer (source > pointer) to > avoid using #become: at all. > this won't deal with VM bug per se, but at least prevent it from triggering. > > No, that makes little sense. Instead provide me with a reproducible case and I'll fix it quickly. I fixed the case form last week in one day. Become: should work, but I can't fix things if I can't reproduce the bugs. So please take the time to produce an image that crashes from start-up. > > > > On 25 February 2013 23:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > he is talking about some chrashes that happens fast, when you do become :) > > > > nothing about "fast become" > > > > On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > > wrote: > > > > mmm what do you mean by "fast becomeForward:" ? > > > > On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni <camillobruni(a)gmail.com> > > wrote: > >> > >> While setting up the new multi platform VM tests I saw that the tests fail > >> extremely quickly > >> when there are not PharoV10.sources available. > >> > >> It is still our know #becomeForward: but on CompiledMethods, but I just > >> want to share that. > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Best regards, > Igor Stasenko. > > > > > -- > best, > Eliot

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Martin Dias

> I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful > here? Are you talking about an specific pragma for deprecation? I didn't catch it.

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Marcus Denker

On Feb 28, 2013, at 2:07 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> (We really need to clean up the MethodFinder, it references a lot of >> crap). > > I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful > here? > I don't know. The small fix we can do immediately. Cleaning MethodFinder needs serious thought and work, so if that is the issue where will be no progress for a while. Let's clean the trivial thing *now* (that is, when 3.0 is started), and add a second issue for the MethodFinder. As for it: it uses positive tagging. "It is ok to run this method as there are no side effects". Do you want a pragma in *every* method? I don't. For things like this we need a way to associate meta data with methods that is a bit less intrusive, yet stored in a way that it is not lostâ¦ And maybe it should be part of MethodFinder, not part of the method itself. Marcus

Feb. 28, 2013

Re: [Pharo-project] test job

by stephane ducasse

>> > > Olin Shivers: "I object to doing things that computers can do." Amen. > > Automating your builds keeps you honest! oh yes and this is why we have been working on a full bootstrap :) because we will identify old dependencies and rotten skeletons even if we made already huge progress. > > frank >

Feb. 28, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by Sean P. DeNigris

Marcus Denker-4 wrote > (We really need to clean up the MethodFinder, it references a lot of > crap). I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful here? -- View this message in context: http://forum.world.st/String-asPacked-fromPacked-tp4672413p4672687.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 28, 2013